Skip to Content
Author's profile photo Former Member

Post Teched questions on HANA

SAP and others have been talking a lot about in-memory computing. I honestly thinking that HANA will be a big game changer for SAP – especially if it also has a mobile play. As I processed the information I gleaned from Teched over the last 24 hours snce I left Vegas, I have a few questions.


Server vs Client – Is it all about Shrek? what about Donkey?


The point I want to make here is – with all the talk about big blade servers holding data in RAM, and having 64 (well 128 soon) cores to process it, what is the role of clients?Does it matter at all whether client side machines have any power or not? Here is what I think. 


A lot of innovation is happening in the semiconductor world for chips that run in mobile devices. Every generation of these processors make them more powerful and generate less heat. One day soon, we will have mobile processors that can do extremely powerful calculations. I actually think that more innovation is happening on this than on the processors that are specific for servers. 


Despite this, all the applications like HANA seems to depend on server side processing and memory alone without considering the possibility of using the power of client machines. I think this is a missed opportunity. While it is obvious that efficient server side processing is a mandatory primary requirement for in memory computing,why would you waste resources that are available?


I would think that an approach of “go where there are resources” is more suitable. It is not very hard to find out the processing power of client machines at run time. So if you can figure it out, then the excess server side power canbe used for something else.


Similarly, for mobile devices – the big restriction is bandwidth. So if client side resources can be used intelligently, may be the requirement to send roundtrips to the server can be minimized.  In a powerful mobile device, a lot of things like visualization, scrolling and so on can probably be handled on client side without server needing to worry about it. This should be a big improvement in user experience.


If you have a big jack hammer, will you look for a nail every where?


I get the idea of doing analysis fast. What I do not completely comprehend is the quantity of data that needs to be analyzed to take decisions.If you have 20 billion records in your system, would you put all 20 billion into your in-memory system? What is the value in that? 


Since the world around us changes frequently, I have always felt that the importance of analyzing vast amounts of historical data  to make decisions is some what over rated. There are exceptions – I readily agree – but I would think in most cases, you don’t have a real need to analyze data that is really old. Also, I am not sure if HANA has inbuilt predictie analytical abilities .


Same is true on what parts of your data will you load into HANA. Not all fields are relevant for reporting. So do you make a distinction in what you load into HANA? or would you load everything into it just because you can? I would like to think that you do some data modelling in HANA and choose the information that is relevant for reporting. But that means that we some how have to define upfront what reports we can and cannot run.


Read and write with same efficiency?


I readily admit that I am not a big expert in the theory – but from my limited understanding, I feel that columnar databases are better at reading than at writing. So to make in-memory computing work – I guess there are two separately optimized parts at play under the hood – one that reads efficiently and one that writes data efficiently. Which would also mean that frequently these two things will need to be combined. I would GREATLY appreciate some insight into how this works, if some one can explain it. I stopped by the Hasso Plattner Institute pod yesterday, but could not find any one to ask this. The guys and gals in white lab coats next door seemed pretty busy with a big crowd around them. Too bad I could not organize my thoughts early in the day, and chase some one down to ask for a clear answer.


Is price-performance enough to make customers switch?


I understand now that price-performance is in HANA’s favor for sure. But that is not how most companies decide on CAPEX budgets. Blades are not cheap – just because SAP could get their sandbox for half a million dollars cannot be extrapolated to mean that customers will get similar prices. And customers who have heavy investments in hardware and database licenses already will need an extra value proposition beyond price-performance to make the switch. I am sure the top 100 customers or so will make the move, and get the benefits. But if this has to become mainstream, I think a lot more business value needs to be shown.Maybe this will happen over time – with SAP and partners making a lot of industry specific analytical applications that make use of HANA.


What about BW?


No one told me officially so far that BW will die if HANA becomes mainstream. Thousands of customers use BW – so I can see why SAP cannot scare them. But over time – and not a long time, say maybe 5 years or so – I would think that HANA can replace BW, BWA, Explorer and so on and serve as a super datawarehouse. If it does not do that, and if you need parallel BW, BWA systems etc I think that is a big let down. I would like to think that SAP can somehow come up with an automated migration of BW on to HANA, without customers having to rip off BW and rebuild in HANA. Again, if some one knows any plans for this – please share. 


What about data federation?


I am told that HANA comes preloaded  with BO tools. I assume this includes datafederator with the common semantic layer. So if 70% of the enterprise data sits in HANA and 30% in other systems, will the data federator within HANA be able to combine virtual data from elsewhere with the data it is holding in RAM? or will the approach be that we are better off by physical transfer of the remaining 30%  data also into HANA? 


That is it – I think I get the rest of the story pretty well.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Richard Hirsch
      Richard Hirsch

      1. I agree that the current focus for HANA is on server processing. Improvements in client processing power should also be used. The problem is that there is no single type of client. To enable client processing, you would have to develop for clients of different processing strengths - it would similar to a return to developing for different browsers. This would increase complexity for developers who use HANA technology.

      2. Excellent point regarding the selection of data to go into HANA. I've read elsewhere that in-memory technology might actually lead to sloppier data management. Because HANA is so fast, I can load everything into memory without selecting those areas that are actually relevant for analysis.


      Author's profile photo Nathan Genez
      Nathan Genez
      as a comparison, virtually all of the BW performance tools are db related. not sure what solutions exist in the IT market but SAP hasn't been able to do much for the frontend other than caching or precalculating.

      I'm not a huge fan of BW because its admin cost is too high but one offshoot of that it is that it forces a more disciplined and rigid design. 

      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Dick, I would think somehow the multiple client issue can be solved by staying away from point to point solutions for each front end, and doing more research on cross compiling one solution on many different platforms. In innovation weekend, we were shown such an option between IOS and Android.
      Author's profile photo Mark Finnern
      Mark Finnern
      Hi Richard and Vijay,

      2. Excellent point regarding the selection of data to go into HANA. I've read elsewhere that in-memory technology might actually lead to sloppier data management. Because HANA is so fast, I can load everything into memory without selecting those areas that are actually relevant for analysis.

      You never know when you need some extra information. If the performance is O.K. I would put everything in. Most frustrating from my profitability analysis days was to realize the missing field that would solve a problem. You never know which one.

      With the immediacy of the answers you get from the system, your frequency of questioning increases and with that your venturing into territory that until now you wouldn't do. By doing so you may discover interesting correlations. In the future you will have bots doing this correlation work for you and present you with things to look deeper into. Going to be interesting times, Mark.

      Author's profile photo Ethan Jewett
      Ethan Jewett
      Thanks for the blog and thoughts Vijay. Very insightful.

      Just a quick word on the way that HANA and BW appear to fit together: Keep in mind that HANA is currently (as far as I can tell for the relatively sparse information available) positioned as a data store that is well-optimized for analytical applications. It is not a data-warehouse in the traditional sense, though it does appear that it is well positioned to fill the need for simple data-marts.

      Meanwhile, BW is a data-store-agnostic data-warehousing toolkit. So, you can see where this is going...

      It looks to me like this first version of HANA is basically going to replace BWA vis a vis BW, but my understanding is that the end-goal is to allow use of HANA as the primary BW datastore, with BW providing the toolkit to architect and manage your datawarehouse residing in HANA. I think it's likely that more and more BW functions will be supported internally by HANA, allowing for processing to remain closer to the data. For example, in addition to the MDX engine and storage engines that HANA provides, maybe some of the processing of the BW OLAP engine or the data distribution services (transformations and DTPs) will be run by HANA and not the BW system.

      In any case, I agree with you that customers and partners need more information. In my view, SAP should provide one (or preferably both) of two things in order to enable good decisions around purchasing HANA:

      1. Detailed information about the internal technical workings of the appliance.

      2. Detailed and exhaustive benchmarks, preferably on industry-standard measures such as TPC or TPC-H

      Claims of large speed-ups and lighting-fast in-memory processing are nice, but without making available the information to back them up they are just marketing.

      Author's profile photo Martin Lauer
      Martin Lauer

      I think Microsoft provides an answer to your question how to use a powerful client PC:

      "Make the most of multi-core processors and gigabytes of memory"

      Kind regards, martin

      Author's profile photo Martin Lauer
      Martin Lauer

      I think it's actually the use case that determines wether you should optimize read access, as for BW applications, or write access.
      Why not both? I guess that's a law of optimization, read and write are different and put constraints on each other and these constraints prevents achievement the same results for read-only or write-only systems.

      This paper from Mike Stonebraker describes C-Store, a read-optimized columnar DB system. It also has a write interface, because somehow the data must be loaded into C-store.

      See also Vectorwise page for read-optimized DB Systems:

      KR, Martin

      Author's profile photo Martin Lauer
      Martin Lauer

      your question why would one want to store all data forever in memory is perfectly right.

      HANA is a new paradigm. You can store all data in memory because it's compressed and that's why you dod it.

      HANA is different. As Vishal said it's about reducing complexity and simplifying the stack, i.e. removing tiers, e.g. the DB tier.

      Personally I think that the concept of Caching is one of the greatest ideas (see also that's why I think (especially since Vishal started the era of AND - i love him for this) that a combination of in-memory, i.e. volatile storage, with a persistant storage (disk,SSD)  will be a perfect fit for most applications.

      Regards, Martin

      Author's profile photo Former Member
      Former Member
      I attented the SAP Teched in Berlin. As far as I understood the HANA approach, that finally it will replace the BI and BWA. Or at least - all will be come again one and then will be based on In-Memory Technology. I also heard, that they plan to have a new database on the in-memory server. At least, that would be a way to get the customers away from the Oracle database. Maybe in some years, you have a big-black-box, which stands in your database but it administrated remoetly by SAP and the hardware vendors.
      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Something I forgot to add to this blog.

      I had a casual chat with an ORACLE employee on my way back from Teched, and he said there are plans to support SAP on exadata. I went and checked their website, and apparently this is indeed true - just that it is not certified by SAP yet.

      Very curious to see how this plays out.

      Author's profile photo Former Member
      Former Member
      Hello Vijay,

      the in-memory technology from SAP is completely
      different from Oracle's Exadata. If you turn off
      the SSDs on Exadata, you have plain conventional
      Oracle database servers. So almost all of the
      performance gain on Exadata comes by eliminating
      the IO bottleneck which stems from (slow) hard
      disks. So if your data fits on SSDs, there is
      no need for Exadata. But even if your data fits
      on SSDs, you would still get benefits from using
      BWA (and hopefully also HANA, let's see the final



      Author's profile photo Ingo Hilgefort
      Ingo Hilgefort
      HI Vijay,

      take a look at the blog from Thomas which clearly articulates why HANA does not replace BW:

      The BW - HANA Relationship