Recently I attended a quite well done presentation regarding SAP’s HANA data storage product and scoured the various websites mentioning HANA. I’m not going to go over the that as all that information is really on SAP’s website.
I was inspired to get access to it last night from a friend so this preliminary review is only from a few hours of hands-on playing with it. Perhaps if time allows I’ll perform an in depth analysis of it.
HANA is a memory resident hybrid OLTP/OLAP/DSS system with aspects of being able to quickly load data from a myriad of sources into memory.
You’re currently limited to 2TB of memory for the data AND any memory required to run HANA including sorting tables. If you’re using SAP business applications, this limit is 4TB. The systems have to be certified by SAP and the software will be installed by the hardware vendor unless you’re certified. There are ways to determine exactly how much memory you’re using but like Sybase ASE’s MDA tables, getting actual utilization requires a lot of patience and hair pulling.
The platform is RedHat Linux on Intel hardware from HANA certified hardware vendors (currently nine vendors).
What happens if the box goes down? There is local storage (or SAN type storage if you prefer) that the memory resident database loads initially from and writes to periodically. When I killed HANA it took a few minutes to recover but most of this was reading from the local storage directly into memory. At this point, I’m not certain as to what extent, if any, that HANA checks the data on load. It seems to perform of checksum on the log records on recovery but I wasn’t able to verify in the time I had available.
In SAP’s marketing literature it says that CPU caches are specifically targeted for high performance of certain types of operations whereas other DBMS systems do not. Again, I didn’t have time to determine how HANA implements it. There are a couple methods that can be done to perform this:
- Run part of a process in kernel space, think kernel module, but this can be quite risky not only from a stability aspect but also security wise. In the early days of Linux, this wasn’t uncommon, now days it is quite rare.
- Write parts of your application, the really time sensitive parts, in assembly language utilizing the capabilities to control what goes where on the cpu to some extent. You’ll find this often with multimedia or cpu intensive applications.
SAP HANA isn’t unique in any of these aspects as all of these have been around for a number years before SAP developed HANA but it is unique that it implements all of them. Is it worth the cost of the hardware and software licensing? It depends.
If you care about performance and willing to pay for it, HANA may be a very good fit for your company.