I received a question on my last post about the Dynamic Tiering feature announced in SAP HANA SPS 9. The question is how this differs from paging. The simple answer is that Dynamic Tiering is a database management feature while paging is a memory management feature. While SAP HANA is an in-memory database, it is able to tier “warm” data in the database through an extended table schema, which is now part of the HANA database catalog in memory, while the primary data image resides on storage that is outside of memory. For an explanation of SAP Dynamic Tiering you can reference this post which includes this slide.
The slide above shows that “hot” data is always in main memory and gets maximum performance, while the primary image for “warm” data resides on storage until it is cached and processed in main memory. As the “warm” label implies, this data has reduced performance but it is still a part of the HANA database. This enables SAP HANA to handle much larger data sets, up to petabytes, and update and query all data seamlessly via HANA tables. With extended tables, HANA manages placement of the hot/warm data on RAM/RAM+Disk respectively and this placement is really not a transparent decision – it is based on a set of algorithms which are HANA internal – these are used to decide which data is hot/warm. However, it is possible to move data between standard in-memory tables and extended tables.
An example of the use of hot and warm data for financial services is given in the referenced SAP post. Stock ticker data can be streamed into SAP HANA for immediate price fluctuation analysis and trading actions (hot) with historical stock price data stored in HANA extended tables for trend analysis and portfolio management.
This is a physical view of the configuration for dynamic tiering. The Extended Storage servers are clustered with HANA servers. To maximize native query performance, the HANA system will ship the query operations to either the hot store or extended storage. Query operations against extended store data are pushed down to the extended storage server, minimizing the load on the SAP HANA database server. When implementing this configuration SAP recommends that the distance between HANA hosts and Extended Storage host should be as short as possible to avoid possible performance impacts on distributed INSERTs, UPDATEs, or Queries.
An ideal configuration would be a converged solution like Hitachi’s UCP, where HANA hosts and Extended Storage hosts can run in separate blades, logical partitions, or virtual machines under VMware. The consolidation of HANA and Extended Server nodes in the same physical host would minimize the performance impact of INSERTs, UPDATEs, and Queries to Extended Storage.
Hitachi can compliment HANA’s dynamic tiering with our high performance, highly reliable, Unified Compute Platform that can be preconfigured for quick implementation, and ease of use. The use of G1000 or HUS VM all flash arrays can further minimize the performance gap between hot and warm data stores. Dynamic tiering is for data that is defined by the application as being warm but there are also degrees of warmth in warm data. Hitachi storage can add another dimension of automated tiering from warm to cool to cold through the dynamic storage tiering capabilities provided by our storage arrays. Hitachi dynamic storage tiering can be automated based on usage or events, protect against double drive failures, and thin provision, allocated but unused space.
If you are considering the use of dynamic tiering to expand your HANA database, consider the advantages of a converged solution, Hitachi UCP with Hitachi Flash storage. For more information on SAP HANA dynamic tiering, see this blog posted by Saiprashanth Reddy Venumbaka on December 17, 2014.