During the BW-on-HANA ramp-up many customers have evaluated copies of an existing BW (migrated to run on HANA) to that original BW (running on a conventional RDBMS which, in the remainder, is referred to as XDB). While many of them were already convinced on the query performance – frequently because they had already been using BWA – they mostly focused on the advantages that they could gain when loading data into BW-on-HANA. This led to the fact that many of them compared runtimes for process chains on BW-on-XDB to BW-on-HANA. I’ve scanned through many emais, PPTs, DOCs etc. that document those efforts. The result is an anonymised bar chart that documents what benefits have been achieved in those real-world scenarios and by the customers on their own.
To state it right at the beginning: this is NOT a performance benchmark in the traditional way with a clearly defined scenario, clearly defined tasks, software, hardware, costs etc. so that the results can theoretically be recreated by using all the information provided. We do not have all the information around those measurements. It is even likely that the comparisons are not perfect: for example, the BW-on-XDB and BW-on-HANA might not have run on perfectly comparable hardware. On the other hand, it is possible that process chains in the original systems have undergone years of tuning (on the respective XDB) while there was hardly any tuning done in the BW-on-HANA context. In summary, this is not perfect but it reflects reality, this is what happens in real customer projects, this is what the product achieves in the real world and this makes those numbers appealing to me.
The bar chart below shows the results of 40 process chains. Each bar shows the runtime of the respective process chain running in BW-on-HANA relative to the same process chain running on BW-on-XDB which is assumed to be 100. For example: process chain #6 shows a value of approx. 20. This means that the runtime of that process chain was only 20% of the original runtime in BW-on-XDB. Or in other words: it ran 100 / 20 = 5 times faster in the BW-on-HANA system. For better visualisation, the process chains were sorted so that the process chains with the most benefit are on the left and the ones with the least or no benefit to the right.
Process chains are load processes that consist of many intermediate steps like reading data, changing or checking data (traditionally in the ABAP server), deriving the delta load (i.e. the data activation in a data store object), writing that delta into one or more targets etc etc. A process chain constitutes an entity that is on a customer’s mind, that he manages, around which he defines SLAs. It describes the entire path from loading the data from a source system to making that data available (visible) to an end user in a cleansed, compliant and consistent way. As such, a process chain is much more tangible in the real world than academic analyses of fast running SQL statements like mass INSERT, UPDATE or DELETE operations.
What can be derived from those numbers?
- Most process chains run faster (blue bars below the red dashed line).
- There are instances that run slower (the three on the right hand side). The reasons here are sometimes non-optimal access of data in HANA, e.g. many individual fetches rather than a few mass SELECTs in (ABAP-based) customer coding.
- The median (process chain #21) is at approx. 40, i.e. 40% of the original runtime or 100 / 40 = 2.5 times faster.
- One comment to process chain #1: by chance, I know that this one has undergone some tuning by rewriting (customer) coding to be optimised for HANA. The result is tremendous as the new runtime is only 3% of the original one, i.e. 33 times faster! This is the other extreme of what has been commented under 2.
In total, the sheer number of loading scenarios that experience a benefit from the migration to HANA is encouraging. Most importantly, they are achieved by using standard tooling and by the customers themselves.