- We have obtained reports of SQL Server outperforming HANA.
- We analyze the hardware specification differences that lie beneath SQL Server versus HANA.
Why are IT departments not noticing that HANA’s performance is so unimpressive versus dramatically less expensive databases?
In the field reports of SQL Server’s performance versus HANA, several customers have been surprised that HANA does not seem to outperform SQL Server for performing similar tasks. But one item is often left out in the conversation in performance comparison.
The Hardware Used by SQL Server Versus HANA
SAP has their customers purchase the largest possible hardware specs for HANA. It is impossible that SQL Server had anywhere near the same spec as the box that was used for HANA. It follows logically that HANA significantly underperforms its hardware specification. We addressed the inability (or lack of interest) by IT directors to account for the percentage of the performance boost was accounted for by hardware as we covered in How Much is Hardware Responsible for S/4HANA’s Benefits?
Ahmed Azmi offers the following take on this topic.
“The only way to compare the performance of 2 DB systems is to run them both on the same hardware. If you run HANA and SQL Server on the exact same hardware, SQL Server will outperform HANA by a wide margin. Give me any database system and I can boost its performance by an order of magnitude simply by upgrading the hardware. If you spend a million dollars on memory and processor acceleration, you can make any database faster. It’s just a matter of throwing more hardware (money) at it.”
As for “in memory” type processing, Microsoft added this to SQL Server back in 2016 as can be seen in the graphic below.
What is HANA?
HANA is two things, and a third thing that is an emergent property of the first two things:
- The Hardware: New hardware, using both high-end RAM and SSDs to push out any spinning disks.
- The Software: A database designed with column-oriented data table store, which is customized for reading access (i.e., for analytics).
- The Hardware Software Interaction: The interaction between the column-oriented data and the memory. This is a well-known feature of the interaction between memory and data stored in as columns which we cover in the article How HANA is Such a Fast Database (For Analytics).
But a major issue, which should be obvious, is that SAP is a software company, and makes none of the hardware that HANA uses. However, SAP is taking credit for performance increases that don’t have anything to do with SAP. And they have nothing to do with the work or innovation of any other database vendor either. However, SAP is the most aggressive in combining the hardware improvement story with the changed software (the database) and allocating all of the credit to SAP, or the software vendor.
Yes, Adding More Expensive Hardware Increases Performance
Also, this is not to say that any system or database that is placed onto more expensive hardware will not improve in speed.
That is always the case.
And here arises the problem in differentiating just what the hardware “bump” is doing versus the overall HANA “bump.” HANA is a combination of hardware (RAM and SSD replacing spinning disks) with a column-oriented table design.
Our Interaction with HANA’s Performance
Recently we received the following message on HANA performance from someone with first-hand experience with HANA.
“I rather like HANA. We migrated from Oracle to HANA… and I like it very much, although I think it would be so much better on different hardware than what we have.”
There was particular hardware that was purchased that our contact would have preferred to be from another vendor. We won’t get into the hardware as that would be a different article.
Our contact when on to laud HANA’s performance for planning runs. The software that was residing on HANA, in this case, was supply chain planning software. And our contact reported a 30 to 50% improvement in planning runtimes.
Isolating the Performance Benefit of the Hardware from the Performance Benefit of the Software
Upon consideration of this improvement, I began to think of what we know that HANA improves regarding performance. And its primary benefit is read access.
Read access is very intensively used in analytics; however, with a planning system. The load is to the memory and the processor for a planning run.
Therefore the question is, why would HANA’s column-oriented design improve the performance of this type of processing?
I asked if it was not likely that the performance was not due to the columns oriented design (which only provide a performance benefit in reading operations) but is instead due to the hardware (the extra RAM and SSD?)
Our contact commented that
“Performance management in the past consisted of optimizing the data flows between CPU, memory, and disk. With in-memory computing, disk I/O has become irrelevant and things that plagued us in the past like disk-layout, RAID configuration, I/O hot-spots, redo-log I/O performance, concurrent/direct I/O and tricky OS settings like IBM’s I/O queue depth have all gone away now.”
But we would point out that these things are true when any system is moved to being entirely in memory.
That is when the more expensive hardware is added.
HANA Efficiency Level with Hardware
There is a lot of discussion by SAP how HANA is so fast. But there is very little information around how well HANA addresses the hardware that it is given. SAP stated that it had the developed the fastest database in the world, and done so on the first version of HANA. But then, HANA has been continually “innovated” since its introduction. HANA is known as one of the most patched databases, and this along with several other factors has to lead to HANA being maintenance heavy, which is accounted for in the Brightwork research A Study into SAP HANA’s TCO.
Information from some sources indicates that HANA requires significantly more hardware than do competing databases to return similar performance results. This would suggest that HANA was not designed as well as competing databases regarding how it addresses hardware resources. And these data points that are available to us are recent, so it can be argued that it was because HANA is in its first version. But let us remember, SAP claimed that HANA was the world’s fastest database in its first release. This performance promoted Jon Appleby of Bluefin Solutions (an SAP consultancy) to state that…
“Oracle if finished on SAP,”
..as we coved in the article How SAP Has Quietly Changed its Strategy on HANA and Oracle.
This fits into comments that SAP uses regarding HANA’s “innovation.”
SAP has converted the term “innovation” into the frequent updates required to patch problem areas, basically to try to catch up to other databases.
Why Hasso Would Like Customers to Upgrade their Hardware
SAP, and Hasso Plattner, in particular, have made a significant point of emphasis that companies need to upgrade their hardware. In four books on in-memory computing, Hasso has stated that companies don’t understand how much it is beneficial to have all of this performance. However, it should be remembered that all of this advice regarding adding hardware is within the context of adding expensive hardware to SAP in particular.
However, the observations cataloged up to this point demonstrate that HANA is not as capable of using more expensive hardware than competing offerings. Furthermore, the inefficiency with which HANA can do things like utilize processors is quite weak. Therefore, the question arises whether SAP is prompting customers to buy such high hardware specifications to compensate for this issue.
Hasso and SAP Oversimplifying
Furthermore, Hasso and SAP are providing an oversimplified perspective on hardware, speed and decision making. Hasso has stated that decisions in health care, surgeons must be made instantaneously, and HANA will be part of that. This is untrue as is covered in the article How Accurate Was Hasso Plattner and Fortune on HANA?. Even in an ER environment, the orientation is to stabilize the patients. Scheduling operating rooms and the right personnel for specialized procedures takes weeks. There is a whole chain of events that take place that the database will not speed up much. I happen to perform extensive forecasting testing, which is very processing intensive. But I can simulate a forecasting scenario for a large company’s data set using just a well-powered laptop. I think I cost me around $1500 at the time. The software I use makes excellent use of quite inexpensive hardware.
Many examples could be provided. And for those that are less interested in the details per se, the result is that more complexities go into the performance equation that what SAP presents to corporate buyers.
Introduction to HANA Development and Test Environments
Hasso Plattner has routinely discussed how HANA simplifies environments. However, the hardware complexity imposed by HANA is overwhelming to many IT departments. This means that to get the same performance of other databases, HANA requires not only far more hardware but far more hardware maintenance.
Development and testing environments are always critical, but with HANA, the issue is of particular importance. The following quotation explains the alterations within HANA.
“Taking into account, that SAP HANA is a central infrastructure component, which faced dozens of Support Packages, Patches & Builds within the last two years, and is expected to receive more updates with the same frequency on a mid-term perspective, there is a strong need to ensure testing of SAP HANA after each change.”
The Complications of So Many Clients and Servers
HANA uses a combination of clients and servers that must work in unison for HANA to work. This brings up complications, i.e., a higher testing overhead when testing any new change to any one component. SAP has a process for processing test cases to account for these servers.
“A key challenge with SAP HANA is the fact, which the SAP HANA Server, user clients and application servers are a complex construct of different engines that work in concert. Therefore, SAP HANA Server, corresponding user clients and applications servers need to be tested after each technical upgrade of any of those entities. To do so in an efficient manner, we propose the steps outlined in the subsequent chapters.”
HANA development environments can be acquired through AWS at reasonable rates. This has the extra advantage that because of AWS’s elastic offering, volume testing can be performed on AWS’s hardware without having to purchase the hardware. Moreover, the HANA AWS instance can be downscaled as soon as the testing is complete. The HANA One offering allows the HANA licenses to be used on demand. This is a significant value-add as sizing HANA has proven to be extremely tricky.
One cannot observe the benefit of HANA without taking into account the more expensive and more modern hardware that HANA brings along with it. SAP proposes that its combination of using column-oriented tables along with more recent and costly hardware leads to a number of different performance benefits. However, adding more expensive equipment to any solution does not require SAP. That is high-speed RAM, and SSD can be purchased without contacting SAP. It can be installed without contacting SAP. And the performance will improve. Furthermore, switching out old hardware for new hardware is one of the fastest ways to improve performance, and not only do you not need SAP, but you also don’t need Deloitte or Accenture, and other HANA devotees to enable this.
As a control, one must know the benefits of HANA versus the benefits of adding more expensive hardware to an existing solution and not employing HANA. Companies that allow SAP to take credit for what is a premium hardware configuration are fooling themselves.
Furthermore, the hardware component is the lowest cost portion of HANA.
- Migrating a current solution to new hardware is the lowest effort of migrations.
- It does not require a reimplementation of software.
- It does not require purchasing a new database license from SAP.
- It is the fastest migration—the data points we have indicated that a HANA implementation takes on average 1.25 years. But a real hardware upgrade is a small fraction of that time.
Why put off what will be in many cases over 1/2 of the benefits of HANA for 1.5 years?
A substantial portion of the overall benefit of HANA can be obtained by merely installing HANA type hardware with the existing database.
It is difficult to see how HANA can match the SQL Server’s performance, given the difference in hardware specification used by HANA. What is impressive about this is that HANA by far the most expensive database of any of the databases that it competes against, and SQL Server is considered the “budget” commercial RDBMS. At this large price discrepancy, SQL Server would further outperform HANA as its low cost would leave more budget to have an even larger hardware specification than HANA.
However, this is not the story; you will hear if you listen to SAP or SAP consulting firms. Yet in the over nine years since HANA’s introduction (this article was updated in September 2019), SAP has yet to produce a benchmark that validates SAP’s claims. This is covered in the article Issues with SD HANA Benchmarks. A new benchmark was created by SAP to cover up this issue as we cover in the article The Hidden Issues with BW EML Benchmarks.
Observe the claims of performance superiority in the following video and our analysis of each point.