8 ms·

I still do not completely understand what SAP HANA really is: - an in-memory database technology? - the name for SAP’s cloud platform? - an on-premise DB to

I still do not completely understand what SAP HANA really is: - an in-memory database technology? - the name for SAP’s cloud platform? - an on-premise DB to run SAP ERP (to replace Oracle)? - a full-stack proprietary web development platform? - a marketing term to solve all problems with SAP products? Does anyone have an hands on experience with HANA, beyond the usual marketing BS? Is is that revolutionary? If it runs on such specialized hardware, is the speed increase that impressive?

lozaning 8y ago
Couldn't tell you what it does, I only know that the advertising of it in airports is ubiquitous. In the dozen plus airports I've been in this year, they've all been plastered in adds for HANA.
sacheendra 8y ago
Don't know specifically about HANA. But, any database with high throughput would benefit from high bandwidth PCIe non-volatile storage. Databases with significant random accesses in their workload would see a large improvement in performance due to Optane. Nothing else apart from main memory matches Optane with its insane random access performance. ERP applications which use HANA typically do have significant random accesses in their workload. It is due to this reason that it was initially marketed as an in-memory database. The random access performance of RAM was necessary for high performance. If HANA was just being used in in-memory mode, the speed increase is probably not that impressive. But, if there is non-volatile storage involved, then yes the speed increase would be impressive.
dijit 8y ago
I have no practical experience with SAP HANA. But I’m a sysadmin and I’ve been to conferences where SAP has had stands and I have a tendency to ask too many questions. SAP HANA is an in memory database. That’s all it is. It’s similar to Qlikview if you’ve used that. It’s licensed per socket, so scaling up is better than scaling out. SAP will also host HANA for you, for a fee. See. The thing is: SAP is a company for HR departments. The kinds of departments that aren’t technical, do not have technical staff to develop thing for them. (It’s an example) but your HR department talks to SAP, they deliver some service, sometimes something that the barely tech-literate members of HR is able to build on and then suddenly your sysadmins have to support those things in perpetuity. Well. They market themselves as this anyway. And I have experience of our HR department buying all kinds of stuff from SAP and their child companies. (Concur, for example). So I understand your incredulous-ness. This company is not made for us. And most of their tech isn’t either.
- toyg 8y ago
  > SAP is a company for HR departments. And finance. And operations. And compliance, and ... > The kinds of departments that aren’t technical Which, in most businesses, are almost all of them. That's why they are so entrenched and so profitable, despite selling an utterly unfashionable and over-complicated stack.
  - tcbawo 8y ago
    Is SAP in the business of selling solutions or technical stack/platform? From what I understand, there is a large ecosystem of private SAP consultants.
    - vbezhenar 8y ago
      AFAIK SAP will sell you a platform and you'll hire consultants who will build solution for your company using that platform.
- IronWolve 8y ago
  We use SAP for finance in many countries world wide, many countries require you to use SAP now so they can give you the tax & legal information for each country in a SAP format to make sure you are up to their countries codes. I suspect they also want information back from you, and most likely in a SAP compatible version. This was all told to me at our IT quarterly meeting, with our new SAP deployments, as IT does not actually input the data, just run the servers. Funny how we run the stuff, but sometimes dont even know how its used.
- Spooky23 8y ago
  The other critical attribute is that it isn’t Oracle. It’s really not in SAP’s interest to have the Oracle guy in there for annual renewals.
kram8 8y ago
HANA was in the first instance a in memory database - at least partly invented by SAP. Because SAP marketing pushed "in memory" so much, all of the SAP employees believed that HANA was the solution to all problems with SAP software. Therefore SAP named all of its products SAP HANA .... Like SAP HANA Cloud Platform, SAP HANA Cloud Integration, etc. Those products were not even related to the in memory database. It's all marketing bullshit and SAP has even taken a few steps back as too many customers were disappointed. Ultimately I think the HANA database is an overhyped in-memory database. The reason they make money with HANA is that they are successfully replacing Oracle Databases for their SAP on-premise customers.
- jdavis703 8y ago
  You forgot about the HanaHaus in Palo Alto, which unfortunately makes coffee at the same speed of all other Blue Bottle locations.
  - farazbabar 8y ago
    This comment is at once so endearing and so alarmingly indicative of the bubble we live.
nevi-me 8y ago
I've used SAP HANA for about 5 months earlier in the year. Between the overselling marketing, the expensive cost of the thing, and the bugs + growing view that SAP are using customers as guinea pigs; I'd say it's like IBM Watson for data. You can get good performance out of it, no medals there as any IMDB would give you that. My pain points were: - it is sold as the virtualisation layer to rule them all, until you find crazy breakages. SAP's SQL dialect is case sensitive. That'll frustrate a lot of downstream databases that you deal with, or the users thereof. - virtual warehouse. I'm not a Kimball expert, but our resident experts came to the same conclusion as I did, that you can't really build useful VIRTUAL data marts directly from disparate downstream data sources without persisting that somewhere. That then defeats the purpose, in my quasi-professional opinion. - I spent over a month looking at the SDA/SDI to "Big Data" parts. Very immature, found interesting instances where push-down of predicates were inconsistent and poor. It's one thing to say you've got Apache Spark integration, but it's another thing when your system can't figure out that data comes from the same system, and this you could do some expensive computations downstream instead of saturating the network pulling a lot of data. I did my work early this year, so I would expect improvement here. The problem though was that many of us started feeling like SAP are releasing a product that should spend more time in development before coming to us. I'm entitled to say so because they charge an arm and a leg. - data modelling/development. SQL is Turing complete, but some things are still hard to do in it. Instead of giving us more capabilities when modelling our data, they're getting "distracted" by wanting to tuck marketing boxes like R support, NodeJS support, etc. I didn't spend enough time on those to feel comfortable with producing a fair opinion, so I'll reserve one. - SDLC, security. SAP has solid products there, and I learnt quite a lot around security integration. There were some quirks, but those were largely because of our requirements, not SAP. I enjoyed working on data access and security patterns. - IDE. They initially used a modified NetBeans, which was also available as a plugin. I'm not a NB person, but this was solid. They decided to move to a web-based IDE. I don't know why, but they deprecated certain things while their web thingy was not even feature complete. It was a growing mess when you'd find that you can only do something in X but not Y. To recap, a high cost for performance that you could get from a competitor, or even a well baby-sat Apache Ignite cluster (for the features they support, at least they aren't lying in their marketing). I think of it as a lame caching layer, that's useful if you're already invested in the SAP ecosystem, think of SAP CRMs or even their warehousing as a stretch. So, no; it's not revolutionary in my view. The "specialised hardware" is marketing bait, our IT (I too was) were convinced that one could build themselves the same hardware as was speced. When I first heard of the special hardware thing, I thought of a custom Intel with features that only SAP would have, DDR4 RAM at crazy clock speed, etc. Only to find that it's a sly way of controlling how much they charge you. "Want to add moar RAMs? Pay us so you don't vid warranty, and we'll charge you more of course for the extra RAM". To conclude my rant, I hope you've found my view useful. My conclusion when I rolled off from my SAP HANA (notice how little I've used this acronym, I despise it) project feeling like it was making everyone in the room bad. People were forsaking their Oracle DBs and Hadoop clusters to make design compromises for an over-marketed database thingy.

lozaning 8y ago

Couldn't tell you what it does, I only know that the advertising of it in airports is ubiquitous. In the dozen plus airports I've been in this year, they've all been plastered in adds for HANA.

sacheendra 8y ago

Don't know specifically about HANA. But, any database with high throughput would benefit from high bandwidth PCIe non-volatile storage. Databases with significant random accesses in their workload would see a large improvement in performance due to Optane. Nothing else apart from main memory matches Optane with its insane random access performance. ERP applications which use HANA typically do have significant random accesses in their workload. It is due to this reason that it was initially marketed as an in-memory database. The random access performance of RAM was necessary for high performance. If HANA was just being used in in-memory mode, the speed increase is probably not that impressive. But, if there is non-volatile storage involved, then yes the speed increase would be impressive.

dijit 8y ago

I have no practical experience with SAP HANA. But I’m a sysadmin and I’ve been to conferences where SAP has had stands and I have a tendency to ask too many questions. SAP HANA is an in memory database. That’s all it is. It’s similar to Qlikview if you’ve used that. It’s licensed per socket, so scaling up is better than scaling out. SAP will also host HANA for you, for a fee. See. The thing is: SAP is a company for HR departments. The kinds of departments that aren’t technical, do not have technical staff to develop thing for them. (It’s an example) but your HR department talks to SAP, they deliver some service, sometimes something that the barely tech-literate members of HR is able to build on and then suddenly your sysadmins have to support those things in perpetuity. Well. They market themselves as this anyway. And I have experience of our HR department buying all kinds of stuff from SAP and their child companies. (Concur, for example). So I understand your incredulous-ness. This company is not made for us. And most of their tech isn’t either.

toyg 8y ago
> SAP is a company for HR departments. And finance. And operations. And compliance, and ... > The kinds of departments that aren’t technical Which, in most businesses, are almost all of them. That's why they are so entrenched and so profitable, despite selling an utterly unfashionable and over-complicated stack.
- tcbawo 8y ago
  Is SAP in the business of selling solutions or technical stack/platform? From what I understand, there is a large ecosystem of private SAP consultants.
  - vbezhenar 8y ago
    AFAIK SAP will sell you a platform and you'll hire consultants who will build solution for your company using that platform.
IronWolve 8y ago
We use SAP for finance in many countries world wide, many countries require you to use SAP now so they can give you the tax & legal information for each country in a SAP format to make sure you are up to their countries codes. I suspect they also want information back from you, and most likely in a SAP compatible version. This was all told to me at our IT quarterly meeting, with our new SAP deployments, as IT does not actually input the data, just run the servers. Funny how we run the stuff, but sometimes dont even know how its used.
Spooky23 8y ago
The other critical attribute is that it isn’t Oracle. It’s really not in SAP’s interest to have the Oracle guy in there for annual renewals.

kram8 8y ago

HANA was in the first instance a in memory database - at least partly invented by SAP. Because SAP marketing pushed "in memory" so much, all of the SAP employees believed that HANA was the solution to all problems with SAP software. Therefore SAP named all of its products SAP HANA .... Like SAP HANA Cloud Platform, SAP HANA Cloud Integration, etc. Those products were not even related to the in memory database. It's all marketing bullshit and SAP has even taken a few steps back as too many customers were disappointed. Ultimately I think the HANA database is an overhyped in-memory database. The reason they make money with HANA is that they are successfully replacing Oracle Databases for their SAP on-premise customers.

jdavis703 8y ago
You forgot about the HanaHaus in Palo Alto, which unfortunately makes coffee at the same speed of all other Blue Bottle locations.
- farazbabar 8y ago
  This comment is at once so endearing and so alarmingly indicative of the bubble we live.

nevi-me 8y ago

I've used SAP HANA for about 5 months earlier in the year. Between the overselling marketing, the expensive cost of the thing, and the bugs + growing view that SAP are using customers as guinea pigs; I'd say it's like IBM Watson for data. You can get good performance out of it, no medals there as any IMDB would give you that. My pain points were: - it is sold as the virtualisation layer to rule them all, until you find crazy breakages. SAP's SQL dialect is case sensitive. That'll frustrate a lot of downstream databases that you deal with, or the users thereof. - virtual warehouse. I'm not a Kimball expert, but our resident experts came to the same conclusion as I did, that you can't really build useful VIRTUAL data marts directly from disparate downstream data sources without persisting that somewhere. That then defeats the purpose, in my quasi-professional opinion. - I spent over a month looking at the SDA/SDI to "Big Data" parts. Very immature, found interesting instances where push-down of predicates were inconsistent and poor. It's one thing to say you've got Apache Spark integration, but it's another thing when your system can't figure out that data comes from the same system, and this you could do some expensive computations downstream instead of saturating the network pulling a lot of data. I did my work early this year, so I would expect improvement here. The problem though was that many of us started feeling like SAP are releasing a product that should spend more time in development before coming to us. I'm entitled to say so because they charge an arm and a leg. - data modelling/development. SQL is Turing complete, but some things are still hard to do in it. Instead of giving us more capabilities when modelling our data, they're getting "distracted" by wanting to tuck marketing boxes like R support, NodeJS support, etc. I didn't spend enough time on those to feel comfortable with producing a fair opinion, so I'll reserve one. - SDLC, security. SAP has solid products there, and I learnt quite a lot around security integration. There were some quirks, but those were largely because of our requirements, not SAP. I enjoyed working on data access and security patterns. - IDE. They initially used a modified NetBeans, which was also available as a plugin. I'm not a NB person, but this was solid. They decided to move to a web-based IDE. I don't know why, but they deprecated certain things while their web thingy was not even feature complete. It was a growing mess when you'd find that you can only do something in X but not Y. To recap, a high cost for performance that you could get from a competitor, or even a well baby-sat Apache Ignite cluster (for the features they support, at least they aren't lying in their marketing). I think of it as a lame caching layer, that's useful if you're already invested in the SAP ecosystem, think of SAP CRMs or even their warehousing as a stretch. So, no; it's not revolutionary in my view. The "specialised hardware" is marketing bait, our IT (I too was) were convinced that one could build themselves the same hardware as was speced. When I first heard of the special hardware thing, I thought of a custom Intel with features that only SAP would have, DDR4 RAM at crazy clock speed, etc. Only to find that it's a sly way of controlling how much they charge you. "Want to add moar RAMs? Pay us so you don't vid warranty, and we'll charge you more of course for the extra RAM". To conclude my rant, I hope you've found my view useful. My conclusion when I rolled off from my SAP HANA (notice how little I've used this acronym, I despise it) project feeling like it was making everyone in the room bad. People were forsaking their Oracle DBs and Hadoop clusters to make design compromises for an over-marketed database thingy.