When you start reading SAP-related publications, it is very hard to find any article that does not mention the word HANA. Especially when you focus on business intelligence, you hear very little about alternative solutions, until today.
In the past months, we have assessed the pros and cons of implementing IBM DB2 with BLU Acceleration on the BW system at one of our customers. For them, it was the perfect layover on their journey from a traditional BW to a state-of-the-art in-memory analytics platform.
To fully appreciate the SAP HANA offering against its competing products, one must first appreciate the difference between an in-memory database and a database with in-memory technology. The former means that the data is always processed in RAM. Data is directed to disk only for secondary purposes, most importantly data preservation in case of outages.
Databases with in-memory technology do the reverse. They are in fact the old-fashioned RDMS-es as we know them. Data is first moved to disk, and from there it propagates to the in-memory areas. At a glance, the two may appear very similar, but in fact, the concept is fundamentally different.
The emphasis in the HANA design is to converge online analytical processing (OLAP) and online transaction processing (OLTP) into one. The design advantage of using an in-memory database is that cache and disk latency is eliminated, and OLAP and OLTP activities can take place in parallel in real time.
BLU is the in-memory acceleration technology in IBM’s DB2 databases. It utilizes several techniques like a column-based organization of data, data compression, parallel data processing optimizations (SIMD) etc. IBM’s DB2 BLU Acceleration takes advantage of a system design where CPU, memory, and I/O are blended in an optimized way.
The data compression in DB2 BLU can process the data more efficiently than SAP HANA, as it does not need to decompress the data prior to reading it. Leveraging its data-skipping technology, DB2 BLU can locate the data blocks of interest and decompress them when needed.
Enterprises that want to merge their OLTP and OLAP into one common environment for real-time decision making, would likely be well served by adopting to the HANA platform. Since all data that is being created is readily and instantly available for reporting, there is no longer a latency, nor is there a need for replication.
Regarding in-memory, BLU and HANA quite comparable to what they have to offer. The table below shows the similarities in their engines.
The examples given by many of our customers may seem obvious, but they have become more relevant than ever: now there is a way to address these concerns faster and more efficiently!
The questions of the previous paragraph boil down to the following set of capabilities. The background color indicates which platform can deliver the capability.
Here it becomes clear that HANA delivers a complete platform and not just some accelerated database platform and optimized storage solution. Depending on needs and budget however, BLU may just offer the right set of capabilities to either fulfill all the requirements or to bridge the period until a full HANA migration is possible.
The hardware requirements for implementing DB2 BLU are quite modest compared to SAP HANA. It may even be possible to implement it on an existing set of hardware.
Especially because not all data needs to reside in memory, a lower amount of RAM can still offer much better performance over a traditional setup.
HANA is an enabler, DB2 BLU an accelerator
BLU is not a real-time solution
BLU now does not eliminate HANA later
SAP strategy
Client tools and connectivity
Interested in the features of SAP HANA and or IBM BLU and how it can help your organization to improve? Feel free to contact us.
