4.1 Step 1: moving one non-SAP application to HANA

In order to understand the characteristics of our Corporate Data Pool let’s start to investigate a single Java application for which we replaced the relational database by SAP HANA as shown in the illustration below. The facts and figures described are adapted from real customer cases.

The application does not use proprietary features so it runs with very little adaptation effort on HANA. The HANA database is loaded with 2 TB of structured source data. At this point we do not do any changes to the original data model but we store everything in columns (instead of rows which is standard for relational database systems). We discard all primary indices from the source database (which usually are a lot) and we do not create any index on the HANA database. In other words: we take HANA like it is out-of-the-box and we import everything without changes.

In the majority of the measured cases the parameters stay within the following ranges:

• Response time for reading from the database (at medium stress level):
  250 – 500 milliseconds
• Size of HANA database (due to built-in compression):
  30 - 40% of source database
• Increase of response time with increase of parallel requests (at identical number of CPU cores):
  0,25x – 0,5x (non-linear)

All the measurements of been made with real data from production, not with synthetic data.

Summary of findings for a single Java application on HANA:

• Extremely low response times
• Significantly lower data footprint
• Massive parallel query execution (dependent on number of cores)
• Application runs almost instantly 
• All of this comes out-of-the-box without any extra effort for data modeling or performance tuning 
• The original database server can be shut down