Skip to Content

With the release of SAP HANA 2.0 SPS 02, HANA dynamic tiering has introduced some exciting innovations:

  • Multistore tables for partitioning data across HANA memory and dynamic tiering disk
  • Intelligent “results caching” to significantly improve performance of cross-tier SQL join operations
  • Support for HANA system replication for high availability and disaster recovery

Adoption of dynamic tiering is on an upward trend!  Customers have begun incorporating dynamic tiering into their HANA systems to manage ever increasing volumes of data – keeping active data in HANA memory, and moving older data to dynamic tiering.  With multistore tables, data modeling is not impacted by adding the dynamic tiering disk store, allowing for quick implementation, and a seamless experience.  Enhanced query optimization, results caching, and improved efficiency in cross-store data transfer options have elevated dynamic tiering performance to levels that are meeting and exceeding customer expectations.

I want to share with you a compelling customer implementation that demonstrates how HANA dynamic tiering is delivering on the promise of low TCO warm data management for native HANA applications.

In this scenario, a customer in the electrical and gas utilities industry has implemented a billing application in HANA.  Their billing application queries large volumes of meter data, to measure how to properly bill users for energy resource consumption.  The HANA system is managing about 24TB of meter data, and is configured as a 5 node scale out set up, with an additional dynamic tiering (DT) node to handle older data that does not need to reside continuously in memory:

The HANA machines are powerful – each with 144 cores (288 threads with hyperthreading), and 6TB of RAM.  The dynamic tiering server, by contrast, is running on much smaller commodity hardware – 72 cores (144 threads with hyperthreading) with 512GB of RAM.

The database tables for meter data usage are implemented as multistore tables.  Multistore tables are HANA partitioned column tables with some partitions residing in HANA memory and some partitions residing in the dynamic tiering disk layer.  The billing application is highly parallelized with 999 concurrent threads performing processing.  Each thread reads the multistore tables, working on independent subsets of primary keys.  A billing run with all data in HANA was executed as a baseline, then 25% of the older data – approximately 6TB – was moved to dynamic tiering.  (The ALTER TABLE…ALTER PARTITION SQL statement was used to move partitions of data from HANA to dynamic tiering.)  After the data was moved, the billing run was executed again.  Here are the performance results:

  • All data in HANA: 5M records processed per hour, for a duration of 53 minutes
  • 75% of data in HANA and 25% of data in dynamic tiering: 4.6M records processed per hour, for a duration of 58 minutes

With 25% data moved to dynamic tiering, running on a relatively low cost commodity machine, the performance of the billing application was reduced by only about 10%.

This is a very impressive result!  The customer has freed up 25% of HANA memory for hot data processing, has moved off older data to a cheaper processing tier, and is still achieving excellent performance – within 10% of pure HANA.

To learn more about dynamic tiering, check out our HANA dynamic tiering developer page: https://www.sap.com/developer/topics/hana-dynamic-tiering.html

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Jens Gleichmann

    Hi Courtney,

    thanks for providing an insight into this customer scenario. It is a good starting point for a TCO to show the benefits in a DT scenario.

    I think It would be helpful for everyone how much data are behind 25% and how was the load on the DT host during the billing run. Another aspect which came with the spectre/meltdown patch is its performance impact regarding the syscalls (PTI). May be the reduced performance is now over 10% which should than be rerate.

    Another thing you mentioned that this system is a CRM system which is currently not supported as scale-out if it is a BSoH.

    2394124 – SAP HANA 2.0 Dynamic Tiering – Additional Information: “The data aging framework of the SAP Business Suite (including S/4HANA) currently does not support using dynamic tiering.”

    So I think it is a BW system which is connected to the CRM system, correct?

    However, the only certified scale-out hardware with 6TB are 8-socket systems. The biggest and fastest CPU which is supported by SAP is the skylake 8176/8180 CPU with 28cores per socket => 8*28=224 cores. Your setup 288/8=36cores. So I think you are counting the threads with HT which means that 288/2/8=18cores (v3 = Haswell) which is not supported at all for scale-out with 6TB. This results in a scenario which is not helpful for the customer which need a special approvement for it.

    Can you please shed light on this aspects to avoid misunderstandings.

     

    Thanks & Regards,

    Jens

    (0) 
    1. Courtney Claussen Post author

      Hi, Jens:

      Thanks for the thorough review.  I have made some updates to the blog post to clarify some of your points:

      1. The HANA system is managing about 24TB of meter data (raw, before moved into HANA).  25% of the data (6TB) is moved to DT.
      2. The load of data from HANA to DT was accomplished using the ALTER TABLE…ALTER PARTITION SQL statement to move entire partitions of data from HANA memory to dynamic tiering
      3. I clarified that this is a billing application implemented in HANA – not Business Suite CRM
      4. The previous diagram showed 288 cores for HANA machines, and 144 cores for DT machine.  You are correct that these are the numbers of threads.  The HANA machines each have 144 cores, and the DT machine has 72 cores.  The HANA and DT machines are 8 socket machines.  Hyperthreading gives each core two processing threads.

      I hope this answers your questions.

      Thank you.

      (1) 

Leave a Reply