Government // Enterprise Architecture
Commentary
5/1/2012
01:24 PM
Doug Henschen
Doug Henschen
Commentary
Connect Directly
Google+
LinkedIn
Twitter
RSS
E-Mail
50%
50%

Hana and Exalytics: SAP's Hype Versus Oracle's FUD

Getting to the facts in the war of words surrounding SAP's Hana and Oracle's Exalytics platforms.

In addition to coming up with new applications designed to take advantage of Hana's speed, SAP also has updated major products like BW and its Business Planning and Consolidation module to run on Hana "without disruption." By that, SAP is promising that running those products on Hana will be a simple software upgrade with no tedious changes to the underlying applications. Running on Hana, BW is said by SAP to deliver sub-second query results that would require minutes or hours with BW running on a conventional database. Similarly, Business Planning and Consolidation activities happen in near real-time without requiring data summaries--data aggregations that are usually required by conventional databases.

Oracle walks a fine line in slamming Hana, because Oracle is also pitching the benefits of in-memory in its own products. Kurian walked this line during Friday's webinar because on the one hand he was touting Oracle's in-memory database, TimesTen, and its supporting appliance, Exalytics, while also slamming Hana. Early on, for example, Kurian noted that DRAM costs have shrunk by 25 times over the past 10 years and he said in-memory response times are "50,000 times faster than going to disk." Yet at the conclusion of the webinar, Kurian asserted that "in-memory is an additional technology that helps people get more value from their databases, but it is not meant to be a replacement for their databases."

It's this is the kind of remark that has led SAP to accuse Oracle of trying to preserve the past and, with it, all the lucrative database licenses it has in place. Where SAP says a single Hana database will eventually run both BW and core transactional applications, Oracle Exalytics is an add-on product (for all but the smallest data marts with less than a terabyte of data). That means an SAP customer running Oracle will still need one database license for the transactional database, a separate license for the data warehouse database, and a third database license (either TimesTen, Essbase, or, in some cases, both) for Oracle Exalytics.

[ Want more on Oracle Exalytics? Read Oracle Exalytics: When Late Is Better Than Never. ]

What's more, in Oracle's old-school approach, transactional data is copied from the application environment to the warehouse and yet again to Exalytics if it's needed for hot queries. So that means three layers of servers, storage, integration, and administration of all of the above.

"Not only do you end up with three copies of the data, you have to add the latency required to move data from one copy to the other," says Gartner analyst Don Feinberg. "The real promise of Hana is that when the transaction is done, the data is instantly in the data warehouse and your analytics become real time."

The promise of Hana is compelling: Running transactions and analytics on a single database, cutting out layers of infrastructure, eliminating redundant data aggregations and materialized views, and doing it all with ultra-high performance. The reality check here is that Hana won't be able to run core transactional SAP enterprise applications until late this year at the earliest (it's already running the BusinessOne service, in beta, but that's not core ERP). Even then, the initial release will be in "ramp up" mode, meaning among a select group of customers. General availability might take another six to eight months.

Meanwhile, one of Oracle's key points about Exalytics is that it improves the performance of existing applications--Oracle's entire portfolio of apps as well as third-party apps--without any changes. Yes, the downside of sticking with the status quo is that you'll have to keep paying for all those databases and related infrastructure. But the upside is that you can keep running the old apps while giving them a performance boost. That's another reason why SAP has to show that its new, Hana-based applications aren't just faster (Exalytics can do that); they have to be better and deliver more business value.

Hana can run existing applications just like Exalytics. But SAP is going to the trouble to build new apps because the old ones simply weren't built for real-time decision-support. For example, speeding up query results won't help if you're still looking at yesterday's data. And even if you can tap into data with low latency (which Oracle can do with its GoldenGate data-integration technology), you still might not increase business value if you can't plug real-time insight into real-time actions.

Oracle knows this as well. During a question-and-answer session at Oracle Open World, where Exalytics was announced, a group of Oracle applications executives acknowledged that they would be developing new apps specifically to exploit Exalytics. There's no sign of them as yet, so for now the party line is that all existing Oracle apps work with the new appliance, getting the benefit of faster performance (meaning query acceleration).

Previous
2 of 3
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
UliBethke
50%
50%
UliBethke,
User Rank: Apprentice
12/24/2012 | 9:17:55 AM
re: Hana and Exalytics: SAP's Hype Versus Oracle's FUD
SAP Hana can't really be compared to either Exalytics or Exadata. Oracle has no similar product that can currently compete.

For my full two cents have a look on my blog: http://www.business-intelligen...

brian9p
50%
50%
brian9p,
User Rank: Apprentice
5/31/2012 | 4:17:42 AM
re: Hana and Exalytics: SAP's Hype Versus Oracle's FUD
SAP has a plan to migrate its large base of application users to its database platform. It already has the fastest growing share in the database market and is eyeing the number two position by 2013 http://www.informationweek.in/...
Amyn Rajan
50%
50%
Amyn Rajan,
User Rank: Apprentice
5/8/2012 | 5:36:29 PM
re: Hana and Exalytics: SAP's Hype Versus Oracle's FUD
HANA does support the MDX query language. In fact, Simba worked very closely with SAP to build MDX capabilities directly into HANA. Uwe Fischer from SAP and I presented at the SAP BI conference in March this year how you can easily connect from Microsoft Excel to SAP HANA using OLE DB for OLAP (ODBO) and the MDX query language.

From the Oracle side, the Oracle database does not support the MDX query language natively like HANA does. For Oracle database OLAP Option, you need to separately license the Simba MDX Provider for Oracle OLAP to get this capability.

Oracle Times Ten also does not support the MDX query language.

Oracle Essbase does support the MDX query language. However, Essbase only supports XMLA and does not support ODBO. Therefore, many applications like Microsoft Excel will not be able to connect to Essbase using the MDX query language.

To summarize:

SAP BW - MDX (yes), ODBO (yes), XMLA (yes)
SAP HANA - MDX (yes), ODBO (yes), XMLA (yes)
Oracle database OLAP Option - MDX (add-on from Simba), ODBO (add-on from Simba), XMLA (coming soon from Simba)
Oracle Times Ten - MDX (no), ODBO (no), XMLA (no)
Oracle Essbase - MDX (yes), ODBO (no), XMLA (yes)
Sam Iam
50%
50%
Sam Iam,
User Rank: Apprentice
5/2/2012 | 8:11:44 PM
re: Hana and Exalytics: SAP's Hype Versus Oracle's FUD
Exactly, they will need some sort of redundant clustering configuration before anyone uses HANA as an RDB. If it is just a stand alone x86 server with a ton of DRAM, the chances of failure are way too high for a production DB. Even if the process of reloading data from HDD is simple (and there are no compression, dedup, transformation processes), it is going to take awhile for HANA to reload several TB of data from HDD to any location. You are back to the HDD IOPS bottleneck issue.

Another issue that concerns people about HANA is that SAP seems to be pursuing an Oracle "own the stack" strategy. Originally they were an ERP provider, then they added Netweaver and became and application server and pseudo middleware provider, then they added BI and DW, now they have Sybase and HANA and are becoming a database provider. They say that they will be an open provider, preserve choice, etc, but they will have a great deal of power over accounts that are SAP from DB through applications.
Sam Iam
50%
50%
Sam Iam,
User Rank: Apprentice
5/2/2012 | 7:50:27 PM
re: Hana and Exalytics: SAP's Hype Versus Oracle's FUD
Where am I supposed to "do my home work"? SAP has zero implementations of HANA as RDB, it's not even supported at this point. There is no documentation on HANA for RDB.

"This is real stuff. HANA simply reads the data from disks on startup that is intitially required in RAM."

I get it. How long does it take to rebuild a few TB from disk to DRAM in the case of a memory error or server failure? What happens to all of those IOs that occur in a live OLTP database when HANA is not online? How does it sync the HDD copy to the production DRAM instance to enable near real time fail over so your primary RDB is not down for an extended period? They will have to answer those questions before anyone puts a live SAP RDB on HANA.

"Businesses are screaming for realtime access to OTLP data. It has always been so problematic and the pain runs deep."

I am familiar with the IOPS bottleneck coming off of HDD. My question is, does closing this bottleneck and improving OLTP response time "transform" anyone's business, especially SAP's core industrial and retail accounts? If you can get an materials config processed at GE half second faster or process a POS transaction at Wal-Mart half a second faster, what are the concrete cost savings or new revenue opportunities? The situations where it might be transformational are in the industry where SAP does not have a strong account base, financial services.

"Data latency is problematic and data duplication baloons the storage cost of traditional warehouses"

Are you talking about databases or data warehouses? Data latencies are generally not an issue in data warehouses. Various in-memory, SSD, massive parallel processing and columnar compression technologies have been around for years. You can make a data warehouse perform at insane rates with something like a Netezza appliance or TM1 for small workloads capable of being run entirely in DRAM.

It is not as though SAP does not use dedup/compression and you do not pay for it. It is baked into HANA instead of being a separate appliance.

This could be as good as SAP thinks it is going to be, but at this point they have an in-memory DW. I will await the details of the RDB.

D. Henschen
50%
50%
D. Henschen,
User Rank: Author
5/2/2012 | 4:06:41 PM
re: Hana and Exalytics: SAP's Hype Versus Oracle's FUD
Good comments. Indeed the current Hana platform includes backup to SSD, and SAP claims it's simple matter to restore. SAP hasn't released Hana support for transactional environments as yet, but CTO Vishal Sikka tells me it will certainly be adding all the high-availability and workload management tools you'd expect to run mission-critical applications. Another case of SAP confidence, but the market will have to vet these capabilities once they're available. Ramp up is expected late this year, so don't expect GA until mid to late 2013 at the earliest. --Doug Henschen
GPATEL000
50%
50%
GPATEL000,
User Rank: Apprentice
5/2/2012 | 1:19:36 PM
re: Hana and Exalytics: SAP's Hype Versus Oracle's FUD
Please do your home work and do not imagine. This is real stuff. HANA simply reads the data from disks on startup that is intitially required in RAM. No transformations are required since the data is written and stored once and transformations done dynamically as the data is accessed in main ram.

Businesses are screaming for realtime access to OTLP data. It has always been so problematic and the pain runs deep. Data latency is problematic and data duplication baloons the storage cost of traditional warehouses
Sam Iam
50%
50%
Sam Iam,
User Rank: Apprentice
5/2/2012 | 1:32:33 AM
re: Hana and Exalytics: SAP's Hype Versus Oracle's FUD
The largest issue is that DRAM is still not a persistent state storage medium. If your server crashes or you have a memory error, all of that data goes away. I imagine SAP would recommend you keep a spare copy on SSD or HDD, but how long will it take to transform the data into whatever format is required for HANA DRAM, ensure that the logs are concurrent, load a few TB of data back on to DRAM, etc? Probably quite a while. That isn't going to work in an OLTP order management system or a similar workload with constant IO. They will need a RAC or PureScale equivalent, some technology that can keep the HANA DB up and running with a primary server failure, before it takes on Oracle or DB2.

As you mention, I don't think there are a bunch of people screaming about the need for millisecond response time from OLTP workloads, especially in SAP's core industrial and retail accounts. In your average tire manufacturer or food CPG company, there are no "transformational" effects of getting .01 instead of .24 second responses to queries. It is kind of a solution in search of a problem. In OLAP workloads, in-memory BW has been around for awhile, such as IBM Cognos TM1 or Oracle Hyperion Essbase. There may be specific applications where this makes sense, but not across the board until DRAM gets to be on par with the cost of HDD.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest - July 22, 2014
Sophisticated attacks demand real-time risk management and continuous monitoring. Here's how federal agencies are meeting that challenge.
Flash Poll
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
A UBM Tech Radio episode on the changing economics of Flash storage used in data tiering -- sponsored by Dell.
Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.