Applications Services Blog
Get the latest thought leadership and information about the role of Applications Services in an increasingly interconnected world at the HP Blog Hub.

In-Memory Computing, SAP HANA takes the lead

 

By: David Bullock, SAP BI/HANA Lead, HP Enterprise Services

 

I recently did a search on Google after a customer asked about the current state of the market for in-memory databases. In the results was a blog by Steve Wilson (VP at Violin Technologies) titled “In Memory Computing, Boom or Bane for Storage?”  It discusses the in-memory features of the new release of SQL Server 2014.

 

In the blog, he raised some very interesting points about in-memory databases that are worth evaluating. They were:

  • Business data needs to be stored safely on a mature persistent media.
  • Business data needs to be accessed via multiple servers for high availability.
  • Systems need to scale over time.
  • Virtual machines need to migrate between servers.
  • New data is received and created constantly.
  • DRAM is a finite (and a relatively expensive) resource.
  • High DRAM memory models, require high processor counts, and can reduce server utilization.
  • Reporting systems can have a very large footprint (well beyond DRAM scaling limits)
  • Loading data into the system needs to be timely (evaporating maintenance windows)

It really got me thinking. Although these points were aimed at explaining why MS SQL Server 2014 is a good product, the reality is, they point to why SAP HANA is an even better product.

 

In his blog he states “If we could hold all SQL Server data in-memory using server DRAM, performance would be amazing, servers would be well utilized, applications would fly – but the reality is businesses have requirements other than just performance.”

 

This is exactly what SAP themselves have found with SAP HANA. It has improved performance in SAP’s own products to a remarkable degree. Some examples include: reporting in the SAP ERP ECC 6.0 has improved up to 1350 times faster; Manufacturing Resource Planning (MRP) runs are up to 4 times faster; retrieving Sales and Distribution Documents are 62 times quicker. (Note: this is old information; it is likely that performance has improved as SAP’s coding improves and design techniques mature.)

 

His first point is interesting: Business data needs to be stored safely on a mature persistent media. SAP HANA does store business data, writing logs of data transactions straight to disk. The difference is that the log data is not used as part of the database’s operation. Like all commercial database products, SAP HANA can create snapshots and full back ups, and can run with a hot swappable online disaster recovery image. Any Database Administrator would have to agree that if you have ever experienced a recovery from disk to disk while the client is watching the clock, they would have much preferred an SAP HANA-like scenario of recovering from disk to RAM in around 10% of the time it takes to recover an image from disk to disk.

 

The next point really makes me scratch my head: Business data needs to be accessed via multiple servers for high availability. SAP HANA has pretty much been scaled out from inception; in November 2012 SAP reported that HANA had worked with 100 scale out machines accessing 1 petabyte of data. 1.2 trillion Rows of data with complex BI queries running in under a second.  

 

He goes on to say: Systems need to scale over time. All systems are sized with growth in mind; SAP HANA can scale over time, have flexible configurations, but sizing is all to do with the design of the landscape and overall solution.

 

In saying virtual machines need to migrate between servers, I’m not sure that Wilson is on the right track. In my view – and I could be wrong – this is an administration issue and normally done through the administration of the Virtual Machine. Note that SAP HANA will soon be certified to run in production on VMWare. This direction was announced by SAP and VMware in May 2013. Other vendors provide cloud solutions for SAP HANA, and HP has its own cloud solution, with solutions for Business Suite on HANA on virtual private clouds (VPC) and appliances.

 

New data is received and created constantly. In 2012, SAP HANA was certified to run SAP Business suite on HANA. It has a sophisticated locking system that fully complies with the ACID principles, is SQL92 compliant and because SAP HANA has shown it can insert 770,000 records per second, it stands head and shoulders above most commercial databases. SAP HANA has been designed for real time data processing either reporting directly off the transaction system or by utilizing SAP Landscape Transformation (SLT) for real-time data extraction into a sidecar SAP HANA reporting system.  With SAP HANA being able to insert such a high volume of data quickly, it removes the relevance of the last point, Loading data into the system needs to be timely (evaporating maintenance windows).

 

Breaking the next point into two parts. DRAM is a finite (and a relatively expensive) resource. All systems have resources that are finite, disk, RAM and CPU. But with a general trend of RAM prices dropping from US$100 per megabyte in 1990 to the current 2014 price around US$0.0073 per megabyte giving the consumer 8 GB of DRAM for as low as US$40 in 2014, it is clear that with Moore’s law and improved manufacturing and technology, it is safe to say that continuing RAM availability will increase and prices will continue to drop for the long term.

 

Some in-memory databases that run across collections of cheaper machines such as Hadoop and Mongo DB, work much like Google. These solutions and architectures are usually about Big Data, and SAP HANA can scale out across multiple machines, providing further dramatic improvements in performance. But in general, a single instance of SAP HANA has between 2 and 4 CPUs, and up to 8 CPUs. (Note that each CPU in HP Appliances such as the DL580 and DL980 can be split into up to 10 cores and the new Ivy Bridge CPUs having up to 15 cores.) SAP HANA can utilize each core and can scan 3.19 billion rows per second per core. This speed combined with both the columnar structure of its data and HANA’s ability to process partitioned data from a table in separate cores, allowing HANA to set benchmarks that are proving to be difficult for other vendors to realize. So, while it can reduce server utilization, so many other aspects of the in-memory database’s design are so efficient that the design of SAP HANA delivers performance as well as efficiency.

 

Reporting systems can have a very large footprint (well beyond DRAM scaling limits). SAP HANA reached a petabyte of data in 2012. But, you have to remember that what makes SAP HANA unique is its absolute efficiency and that reporting from HANA does not require indexes. HANA does not replicate data across the traditional 3 layers (staging, transformation or Data Integration, and access) in a data warehouse, but instead models a view over the raw data, and therefore SAP HANA is able to reduce the size of data significantly. SAP claims a reduction in database size for HANA generally to be around 6:1 and up to 20:1. One article cited that the 100TB SD data set was reduced to a trim 3.78TB HANA database.

 

In conclusion, the article really helped me formulate and understand why in-memory databases are undoubtedly the future for all business processing and why SAP HANA is a revolutionary database. SAP HANA itself is a pure in-memory model, designed and built from the ground up to run in-memory. More importantly the power that SAP HANA has brought to SAP has had a profound effect on the company itself. It has totally refocused SAP on concentrating on the future direction and roadmap of their products. To my thinking this is the true power of SAP HANA. SAP has taken a risk and proved that it is willing to change the internal and external interfaces of their applications to benefit customers and provide real business innovation. SAP has been busy creating very innovative HANA-specific products like SAP HANA Live, COPA Accelerator, analytic products such as Sales Analysis for Retail, Planning and Consolidation for Public Sector and Smart Meter Analytics. From SAP HANA Service pack 9, due in the 4th Quarter of 2014, all of SAP Business Suite products will be able to run in the one instance of SAP HANA. And further in the future, there are plans for SAP ECC 8.0, which is the core of all the SAP products, to run completely natively on SAP HANA. SAP has created a future with real-time processing and reporting in one package.

 

I’m interested in your opinion.  Share your experiences with SAP HANA or other in-memory databases – add a comment in response to this blog.

 

 

HP Enterprise Service provides complete end-to-end offerings to help SAP clients start their journey to becoming a real-time enterprise.  Visit here for more information:

Transformation Services for SAP HANA

HP As-a-Service Solution for SAP HANA

 

Comments
DavidBullock | ‎05-08-2014 12:56 AM

Just a quick addendum to the blog in regards to virtual machines. SAP and VMWare have announded that SAP HANA is now in Production use.

 

http://global36.sap.com/news-reader/index.epx?articleID=22775

 

SAP and VMware Announce SAP HANA for Production Use on VMware vSphere 5.5

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the community guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation