SAP wants to kill Oracle

It’s not new. SAP has been trying to do it for years but with little success. SAP applications and its modules still very much rely on the Oracle database as its core engine but all that that could change within the next few years. SAP has HANA now.

I thought it is befitting to use the movie poster of “Hanna” (albeit an extra “N” in the spelling) to portray SAP who clearly has Oracle in its sights now, with a sharpened arrow head aimed at the jugular of the Oracle beast. (If you haven’t watched the movie, you will see the girl Hanna, using the bow and arrow to hunt a large reindeer).

What is HANA anyway? It was previously an analytics appliance in SAP HANA 1.0SP2. Its key component is the HANA in-memory database (IMDB) and it was not aimed for the general purpose, relational database market yet. Or perhaps, that’s what SAP wants Oracle to believe.

In-memory database seems to be all the rage right now because we storage guys are to blame. I/O bottlenecks from the spinning hard disk drives is putting its tolls onto the performance of databases and in a world where hundreds of billions of transactions go through some kind of databases somewhere, I/O latency is the performance killer.

Traditional databases models, schemas and architecture are built with spinning disks in its design. I/O bottlenecks have always existed, and this was acceptable until the explosive data growth in the last few years. No matter how great the design of the database was, the I/O bottleneck issue has become unbearable. Many has taken into newer, non-relational database architecture to address the big data hype but there is a very large customer base for relational database as well. With the advent of multi-core CPUs, cheaper and faster memory, the in-memory databases (also called main memory database) began to muster greater attention and support.

Instead of relying of slower, higher I/O latency of spinning disks, the in-memory database (IMDB) basically puts its data objects in the system’s main memory. This has its pros and cons but the very obvious effect will be heightened performance.

Memory is about 100-1000x faster than the spinning disks and given the proximity of the memory modules to the heart of the processing of the CPUs and its cores, there is far greater reliability, stability and predictability when the IMDB access its data objects. The IMDB applications also have lesser concerns about queues and buffers when it comes to programming for the IMDB, making it simpler to program, smaller code sets and lighter to execute. Furthermore, the flexibility of the IMDB to store data objects often allows greater compression in the factors of 5:1 or 10:1, giving the advantage of a smaller footprint as well.

But the flip side is memory is volatile. Once the power is off, the content in the memory is erased and this violates the durability component in the ACID (Atomicity, Consistency, Isolation and Durability) properties of any database transactions. But things are changing, because the durability component is supplemented and supported with features such as transactional logging (as all databases do), storage technologies such as snapshots and NVRAM, high availability hardware/software (HA) and clustered file systems. In fact, SAP HANA even proposed a marriage with all-Flash storage vendor Violin Memory in a recent announcement. It’s a win-win situation for both SAP and Violin Memory.

The architecture of HANA Systems is shown below:

It has many components but the main components are:

  • SAP HANA in-memory database
  • SAP HANA Studio – a toolset to administer and model the SAP HANA
  • SAP Netweaver BW 7.3 – an SAP data warehouse solution

SAP has put HANA IMDB to become the lethal weapon to replace Oracle Enterprise DB as the general purpose, core database engine of all enterprise applications. SAP has boldly predicted that by 2015, they will become the #2 database company in the world in the news a few months back.

Oracle has its own in-memory database technology from its acquisition of TimesTen in 2005. IBM, the doyen of the IT industry, took SolidDB in 2008. And rumours has it that Microsoft is building an in-memory DB of their own for their SQL Server.

Will SAP succeed? They have acquired Sybase, Business Objects, SuccessFactors and many other companies to compete with Oracle. But the in-memory database technology it acquired from Transact In-Memory could be the true key to unlock Oracle stronghold in the enterprise database market.

Tagged , , , , , , , , , , . Bookmark the permalink.

About cfheoh

I am a technology blogger with 25+ years of IT experience. I write heavily on technologies related to storage networking and data management because that is my area of interest and expertise. I introduce technologies with the objectives to get readers to *know the facts*, and use that knowledge to cut through the marketing hypes, FUD (fear, uncertainty and doubt) and other fancy stuff. Only then, there will be progress. I am involved in SNIA (Storage Networking Industry Association) and as of October 2013, I have been appointed as SNIA South Asia & SNIA Malaysia non-voting representation to SNIA Technical Council. I currently run a small system integration and consulting company focusing on storage and cloud solutions, with occasional consulting work on high performance computing (HPC).

5 Responses to SAP wants to kill Oracle

  1. Pingback: SAP wants to kill Oracle « Storage Gaga

  2. Pingback: Memory for in-memory databases and SAP HANA | ddr3memory

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.