SAP HANA: A real-time challenge to the Oracle empire

SAP HANA: A real-time challenge to the Oracle empire

Summary: With SAP's claims that HANA enables companies to run arbitrary, complex queries on billions of records in a matter of seconds as opposed to hours, the vendors of old legacy traditional databases are facing a major challenge, most notably the king of them all, Oracle.

TOPICS: Big Data, Cloud, Oracle, SAP

When Tom Cruise's character in Top Gun exclaimed "I feel the need, the need for speed", you'd be forgiven for mistaking it for a soundbite from a CIO discussing their transactional databases.

Whether it's a financial organisation predicting share prices, a bank knowing whether it can approve a loan or a marketing organisation targeting consumers with a new promotional offer, the need to access, store, process and analyse data as quickly as possible is an imperative for any business looking to gain a competitive edge.

The birth and emergence of big data

Back in the days of mainframe, you'd find the application and transactional data of reporting databases physically stored in the same system. This was due to applications, operating systems and databases being designed to maximise their hardware resources, which consequently meant you couldn't process transactions and reports simultaneously. The bottleneck here was cost, in that if you wanted to scale, you needed another mainframe.

After the advent of client servers where applications could run on a centralised database server via multiple and cost-effective servers, scalability was achieved by simply adding additional application servers.

Regardless of this, a new bottleneck was quickly established with systems relying on a single database server and requests from ever-increasing application servers that ended up causing I/O stagnation. This problem was exaggerated with OLTP (online transaction processing), where report creation required the system to concurrently read multiple tables in the database. Alongside this, servers and processors kept getting faster, while disks (despite the emergence of SSD) were quickly becoming the bottleneck to automated processes, which produced large amounts of data - consequently resulting in more report requests.

The net effect was a downward spiral where the increase of users requiring an increase of reports from the databases meant an increase in huge amounts of data being requested from disks that simply weren't up to the job.

Factor in the data proliferation from external users caused by the internet and pressure-inducing laws such as Sarbanes-Oxley, and the demand to analyse more data more quickly has reached a critical point.

With data and user volumes increasing by a factor of thousands compared to the I/O capability of databases, the transaction-based industry faced a challenge that required a dramatic shift and change. Cue the emergence of SAP's HANA.

HANA and the need for speed

In 2011, SAP announced its new in-memory platform HANA for enterprise applications, talking up the potential of real-time analytics. SAP claimed HANA would make databases dramatically faster, like traditional business warehouse accelerator systems, but also speed up the front end, enabling companies to run arbitrary, complex queries on billions of records in a matter of seconds as opposed to hours. The vendors of old legacy traditional databases were facing a major challenge, most notably the king of them all, Oracle.

One of the major advantages of SAP HANA's ability to run in real time is that it offers a non-requirement for data redundancy as it's built to run as a single database.

With clusters of affordable and scalable servers, transactional and analytical data are run on the same database, hence eliminating different types of databases for different application needs. Oracle, on the other hand, has built an empire on exactly the opposite.

Database sprawl

Oracle has thrived on a model where generally companies start with a simple database that's utilised for checking sales orders and ensuring product delivery to customers, but as the business grows they need more databases with different and more demanding functions.

Functions such as managing customer relationships, complex reporting and analysis drive a need for new databases that are separate from the actual business, requiring data to be moved from one system to another.

Eventually, companies have a sprawl of databases as existing ones are unable to handle the workloads, making it almost impossible to track data movements, let alone attain real-time updates. So, while the Oracle marketing machine is also pitching the benefits of in-memory via its Exalytics appliance and in-memory database TimesTen, Oracle is certainly in no rush to break this traditional model of database sprawl and the money-spinning licences that come with it.

Looking closely at the Oracle Exalytics/TimesTen package, despite the hype, it is merely just an add-on product meaning that an end user will still need a licence for the transactional database, another licence for the data warehouse database and yet another licence for TimesTen for Oracle Exalytics.

Moreover, the Oracle bolt-on approach serves to sell more of hardware commodity and justify the acquisition of Sun, all at a cost to the customer.

Due to the Exalytics approach continuing the traditional requirement for transactional data to be duplicated from the application to the warehouse and once again to Exalytics, the end user not only ends up with three copies of the data, they also have to have three levels of storage and servers.

In contrast, SAP's HANA is designed to be a single database that runs both transactional applications and Business Warehouse deployments. Not only does SAP HANA's one copy of data replace the two or three required for Oracle it also eliminates the need for materialised views, redundant aggregates and indexes leaving a significantly reduced data footprint.

HANA vs TimesTen and Exalytics

As expected, Oracle has already unleashed its marketing teams to tout various claims about HANA as well as pushing a TimesTen like-for-like comparison.

Where this is hugely flawed is that Oracle fails to acknowledge or admit that SAP HANA is a completely new design as opposed to a bolt-on approach. With SAP HANA, data is completely managed and accessed in RAM consequently doing away with the requirement of MOLAP, multiple indexes and other tuning features that Oracle prides itself on.

Furthermore, despite what Oracle may claim, SAP HANA does indeed handle both unstructured and structured data, as well as utilise parallel queries for scaling out across server nodes. Oracle presumably is trying to prevent the market from realising that the TimesTen with Exalytics package still can't scale out beyond the 1TB RAM limit, unlike SAP HANA where each container can store up to 500TB of data all executable at high speed.

With an aggressive TCO and ROI model compared to a traditional Oracle deployment, SAP HANA also proves a lot more cost effective. With pricing based on an incremental of 64GB RAM and the total amount of data held in memory, licences are fully inclusive of production and test/development requirements as well as the necessary tools.

SAP embraces VMware

The recent announcement that SAP HANA is supporting VMware vSphere will provide the company with a competitive advantage, as it will enable customers to provision instances of SAP HANA in minutes as VM templates, as well as gain benefits such as Dynamic Resource Scheduling and vSphere vMotion.

By virtualising SAP HANA with VMware, end users can quickly have several smaller HANA instances all sharing a single physical server leading to better utilisation of existing resources. With the promise of certified pre-configured and optimised converged infrastructures such as the Vblock around the corner, SAP HANA appliances could be shipped with vSphere 5 and SAP HANA pre-installed within days, enabling rapid deployment for businesses.

Topics: Big Data, Cloud, Oracle, SAP

Archie Hendryx

About Archie Hendryx

SAN, NAS, Back Up / Recovery, Virtualisation & Cloud Specialist.
Please note that the thoughts, comments, views and opinions expressed in this blog are entirely my own and not those of the company I work for. Content published here is not read or approved in advance by my employer and does not necessarily reflect the views and opinions of the company I work for. Currently working as a Principal vArchitect for the company VCE.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Yes...but...

    HANA is ridiculously expensive and this is before you purchase the required hardware, which is ridiculously expensive. Where comparison is appropriate is HANA against Green Plum or Netezza. In some ways this article feels like HANA, which is agreat technology, acting as a hammer to bash Oracle.
  • Did you mean 500GB?

    In the statement "unlike SAP HANA where each container can store up to 500TB of data all executable at high speed." did you mean 500GB? I don't think one 64GB RAM box can run 500TB of data. Thanks.
    • No they meant and can proof 500TB

      There are several videos as well available on Youtube where SAP has presented first the 100TB Cluster built by IBM for SAP HANA which got now extended. For your information a standard IBM System x Machine can hold up to 6TB of Memory in a single node ;)
  • Incorrect

    Please have the decency to verify this article - it contains many anomalies and mid truths about both Hana and Oracle

    I understand that SAP wish to market HANA as being innovative - but lets be clear the marketing is new and the product is based on old Sybase technology

    SAP have sold less than 200m USD to current customers who are mostly in stalled pilots - due to cost

    vs Oracle who have an install base going back decades with annual database revenues in the billions

    Please ZD editors - Have some integrity
    • Well...

      There are not that many things that can be "wrong" with HANA As it is new...Oracle on the other hand is a well established experience for anyone who deals with oracle and as quarterly earnings calls show, the hardware strategy is DOA. Lastly, your comments are helpful only if you provide an example or two instead of broad statements that are troll like.
    • Your statement is incorrect

      While the article may have inaccuracies overall it is more accurate than your response

      HANA is not based on any Sybase technologies. SAP is apparently looking to incorporate the Sybase solutions with HANA and I am sure some of the technology will be share across both but HANA did not use any Sybase technology as a starting point.

      You might want to go an review the latest SAP quarterly report. I think you will find HANA license and associated revenue is higher than you stated and that there are a number of successful live HANA customers

      Just because Oracle has a successful history doesn't mean it is still the best and can not be challenged.
    • Conflict of interest?

      I presume you are the same Andy Kenney who is "Strategic Account Director at Oracle". If so, I think you should have disclosed that!

      For transparency I run a global HANA practice so I may be biased, but I also know the facts and figures.

      I would agree there are some factual errors in the article and I invited Archie to talk with me so he could hear them. For example HANA currently comes in 128/256/512GB/1TB nodes with up to 16 nodes as standard configuration and more as a custom build. 16TB of HANA is equivalent to around 80TB of Oracle, as HANA compresses data much better.

      However your comment is much more factually incorrect!

      First, HANA is not based on Sybase tech. It is based on a mixture of p*Time, TREX and MaxDB and its existence predates the Sybase acquisition. They are no doubt using Sybase Intellectual Property and engineers to improve HANA, just as they are working on an awesome Database portfolio which includes Sybase ASE and IQ.

      Second, I assume you got your sales figures from the Oracle PR machine :-)

      Sales in 2011 (the first full year of sales...) were around $200m:

      Sales in 2012 YTD are $283m, and SAP did 44% of its revenue in Q4 last year which suggests they may close out 2012 around the $500m mark.

      This makes HANA, I believe, the fastest growing enterprise software product ever.

      As for stalled pilots, I have heard of a few, none of which due to technology reasons. Nothing new there in Enterprise Software. But search the web, there are hundreds of live and happy customers getting 1000x, 10000x and 100,000x performance improvements over Oracle and translating those into top line business results.

      HANA is the future, and whilst I might be biased because I run a practice, it is BECAUSE of that that I chose to set it up in the first place!
      • Aligned Interests?

        The Hana sales figures should be taken with a big grain salt. Software companies have ways of pumping sales figures for one product at the expense of its other products, its perfectly legal but does not mean there is any reality to it, its a trick to make Hana look very successfully.
        I don't blame you for joining the Hana bandwagon since SAP is pumping big money into this so economically it is a good place to be and surely it is also interesting technically. What SAP needs is honest feedback about the big limitations of Hana when compare with established analytic databases. We try it but were shocked when we found all the things hana can not do and how immature it is. And its so expensive...
        • Yes and No

          What you say about how software companies report is of course true, but SAP's software revenues are up substantially this year (4%, 26%, 17% by quarter) and I don't think it is a stretch to think that HANA is a major contributor, especially given the number of live customers.

          I'm not primarily investing because of SAP's investment and because its's interesting - although they don't hurt. The primary reason is because I think HANA is amazing technology that can transform customers' business and drive success. I believe this will create a substantial services market in 2013 and I want Bluefin to be at the front of that charge.

          You have made a few comments about HANA's transactional performance here and I don't know who you work for so it is hard for me to comment on your specific scenario. Up to HANA SP04, SAP focused on Analyitcs performance. In SP04, I found transactional performance to be roughly equivalent to other DBs. We can do 1m inserts a second.

          In HANA SP05, released in November, the team focused more on transactional performance for CRM and the upcoming release of ERP on HANA and this is much improved. Still the point of HANA is to have good transactional performance combined with amazing analytics performance, all without needing copies, aggregates, indexes and other database features that add size, complexity and slow things down.

          So if you are interested in discussing your scenario then get in touch. Maybe the people assisting you didn't do it right, maybe your scenario was not a good one for HANA - I'm happy to assess it with you.

          As for cost, it's hard to comment without specifics but in all the comparisons I have been involved in, HANA wins on cost because it creates simplicity. Fewer, sales line items, lower maintenance cost, fewer connected systems, better business performance.
          • Lost faith

            I think your referring to the loading speed. We were using single-row insert, update and that was slow, even MySQL was faster. We did a proof of concept but we ended up not buying hana, there were just too many problems (not only transactions). We had local SAP techies to support but they had to admit Hana still has problems in many areas. I cannot believe hana will ever win on price its soooo expensive. For me it was a disappointing, I think it will take years for Hana to become reliable.
          • Not what we see elsewhere

            Honestly I can only assume the local people you worked with were not HANA experts.

            We have done so many HANA projects now and insert performance has not been a problem in any of them. In fact, I have one customer we are working with right now where we showed how to do in-memory disaggregation of supply chain information - allowing complex planning scenarios to be performed in real-time, including reporting immediately after disaggregation.

            On reliability, I am amazed by HANA considering she is only 2. So easy to keep stable compared to Oracle where you have to apply hundreds of patches and parameters to avoid data corruption.

            Sorry you had a bad experience and am happy to have a discussion if you would like.
          • SLOW or FAST seems rather subjective ...

            John, what you consider a good performance might be lame for some other requirements.

            Strange enough, if one tries to find benchmarks for the HANA insert rate all one can find are unsubstantiated claims like these rather old posts. Some say it is "good", others say it is "bad".

            So instead of just claiming that the SAP insert performance is "good" (and calling those with other opinions "non-experts") you might convince people by delivering some NUMBERS and simple TEST CASES how these numberes were measured...
          • Yes and No

            Hi John,

            Can you elaborate what scenario would not be a good one for HANA?


            Tan Ah Beng
  • Hana Rules

    SAP has already sold over 1,200 Hana systems and will over take Oracle by 2015. Hana is the most reliable and scalable database I have ever used. With speeds over 10,000 faster than Oracle we were able to decommission 119 Oracle databases. With Hana and SP5 will will be able to eliminate another 100 UNIX based web servers by having Hana directly serve up the pages to any web enabled device. We anticipate the elimination of 78 developers by switching from java to SQL Script. Hana is the most innovate thing since the transistor.
    • ... only if you drink the Kool-aid

      If Hana is the most stable database you've used you have not used many. We have are having endless problems with Hana - performance, stability are all not even close to what we were sold. We have been asking around at TechEd/Sapphire but very few SAP customers who bought HANA appear to use it. Oracle may be able to hype their product but so is SAP.
  • Advertising Jingle

    Sorry, but this article reads like an advertising jingle straight from SAP's promotional literature. I have not used HANA personally, but have been using a similar product from IBM, called Netezza. Its performance has been impressive compared to DB2 on an older mainframe. Netezza is marketed as an optimized hardware and software device. I know that our DB2 is so poorly configured and optimized, that it is refreshing to get a product that works out of the box. I imagine that HANA has similar characteristics. All that said, there has been some overhype with Netezza by IT. It is good, but not miraculous. It is not a 'get out of jail' card for bad database designs.
    • Yes and No

      HANA allows you to get away with a lot, including very large data volumes for transactional and analytical processing at the same time, complex models, no aggregation or indexes etc.

      It shouldn't be confused with Netezza as they are very different by design and HANA will always outperform as it is entirely in memory, compressed and hybrid row/columnar.

      But you are right, an infinite loop will take forever on any platform. Good design is important with HANA to get amazing results. With bad design you only get OK results.
    • Different technology for a different focus

      What you have seen most probably, I figure that from what you have written (DB2& Mainframe), is a specific solution of Netezza for the Mainframe which accelerates large and complex queries. It does indeed give a good acceleration to those queries but is focused on analytic workload only !

      Still cool product with very good use cases 1
  • Hana hardly handles transactions.

    Hana was not designed to run transactions! We tried it and the transaction speed was unbelievably low, the SAP techies admitted thats what it was and they could not make it any better since Hana was not designed for it.
    The threat for Oracle is that Oracle does not have a column database like HANA. The threat for SAP is that Hana ends up as an excessively expensive database that runs best on Powerpoint while remaining too immature.
    • Transactions?

      What were you using to test transactions?
      What type of transactions are those?
      Self-developed transactions or SAP-developed transactions?
      Tan Ah Beng