SAP HANA : Points to ponder
HANA is in-memory technology with the provision of moving business logic to database level instead of doing computation at application server (tradition method) level. This got me to ponder over following points:
a) In traditional approach business logic computation was done at ‘in-memory’; so how is it different when it comes to HANA.
b) As we combining data fetch and processing at single place; will it result in clutter/confusion of development?
c) Row store to column store shift – How will it be with transaction data?
d) In-memory technology usage for transaction systems – Paradigm shift in the way hardware was looked at
e) How HANA can be of help in this highly competitive and fast-moving world to ensure or gain leadership position in the market by being at the edge and sensing the market, customer, and competitors
f) HANA – How it is major shift from traditional approach in terms of overall processing of user requests
g) Big data on HANA (in-memory) is fine as huge amount of data has to be analyzed and processed. But why SAP is/has coming up with ECC on HANA, CRM on HANA, etc…
h) How and what will be the change in ABAP coding with ECC on HANA
i) With calculations moving to HANA; what will be the role of ABAP programmer in performance optimization of the application
I did attend session in my organization on HANA overview and ABAP on HANA. This helped to understand how will HANA be pervasive in near future (in organizations having SAP business software as their business management tool) as it comes with number of features.
- With the options of HANA as secondary database in initial stages of adoption gives IT department of organizations to try out HANA solution without the concern of business activity impact.
- In-memory technology helps to improve application performance by major scale
- Moving the calculation part to in-memory technology with readily available data will be reducing the complexity of the coding from ABAP side
- Extended application services of HANA(full featured application server, web server, and development environment within the SAP HANA appliance) is major shift as full-fledged applications can be realized on HANA with browser as client(please note no intermediaries from plain application perspective)
With number of performance optimizations options in ABAP with ABAP on HANA scenario; it will be paradigm shift in the development is looked at or carried out.
I was involved in POC in which tried to compare the performance of SAPUI5 report (0.2 million sales cycle records- I know it is insignificant when it comes to capabilities of HANA) with traditional ABAP Vs. HANA as backend. In case of ABAP as backend, we used ODATA compliant gateway service for supplying data to SAPUI5. In case of HANA, we used XSJS service as data provider to SAPUI5. We saw major performance improvement of HANA based application over normal application.
good questions...
My opinion to your questions:
a) In traditional approach business logic computation was done at 'in-memory'; so how is it different when it comes to HANA.
=> If the business logic computation was never a bottleneck in term of application performance, then a column-based database will accelerate it in term of database record selection. In traditional approach, developers like to fetch data from DB into application layer for computation. As such, SAP HANA can already speed up this step without adjusting the codes. Maybe minimal data fetching is irrlevant for performance comparision to a traditional row-based DB. However it will make a different when massive record are fetched always.
b) As we combining data fetch and processing at single place; will it result in clutter/confusion of development?
=> SAP HANA has the mechanism in place to database ACID properties are always guaranteed just like any existing row-based DB in market.
c) Row store to column store shift - How will it be with transaction data?
=> SAP HANA can support both column and row tables. Depending on business scenario, you may still use row table if the requirement warrant it that way for better performance and application.
d) In-memory technology usage for transaction systems - Paradigm shift in the way hardware was looked at
=> New technology requires new hardware types to harness the technology power completely. SAP HANA is no exception..
e) How HANA can be of help in this highly competitive and fast-moving world to ensure or gain leadership position in the market by being at the edge and sensing the market, customer, and competitors
=> M(b)illion dollars questions as always 🙂 Check out the link http://www.saphana.com/community/learn for the various HANA solution and the application usage.
f) HANA – How it is major shift from traditional approach in terms of overall processing of user requests
=> Did not understand what it means exactly... For end user, if every database transaction can be processed in real time (ideally), there is no more waiting (batch job) and everything can be analysed and compared in real time.
g) Big data on HANA (in-memory) is fine as huge amount of data has to be analyzed and processed. But why SAP is/has coming up with ECC on HANA, CRM on HANA, etc…
=> In an ideal world, all data should be kept and stored into a single HANA database 🙂 However reality is not.. Data are still arriving from disparate sources and data have to be analyzed within different application for organization usage.
h) How and what will be the change in ABAP coding with ECC on HANA
=> ABAP stays and new syntax/objects are added to allow ABAP developer to harness the power of HANA.
i) With calculations moving to HANA; what will be the role of ABAP programmer in performance optimization of the application
=> ABAP+HANA 2in1 developer in short 😀 Well, it depends on individual if he/she wishes to venture into the HANA territory. A ABAP developer can still focus mainly on ABAP and just execute whatever HANA objects is made available by another HANA developer.
Hi Ganga,
Nice set of questions, these are very common questions that one comes up with while starting to shift to the In-memory paradigm. Hope that this space becomes answer to all those doubts.
Yeu Sheng Teo has answered the questions perfectly, I will try to add my perspective to some of the doubts
a)You are very correct in saying that the logic was always computed in-memory.
But
1.Data was not stored In-Memory,now data is primarily In-Memory:Overhead of fetching data is not anymore.
2.HANA has powerful and massively parallel computing engines which compute the logic fairly faster than the traditional servers.
b)Absolutely not.
Of course Data fetch is the new Data Processing, but this is handled by HANA Information Models very efficiently.
c)Column Store can also handle transaction data very efficiently. The advanced database concepts of Delta and Delta Merge is used. In extreme cases of Write(like 1000writes/sec) HANA automatically makes the Delta as Row-Store, which is fit for Write operations. Delta Merge is where the Delta is merged with the Main Column Store Table. This happens automatically when load on the DB is less in leisure time.
d)Hardware requiremetns for HANA is HANA.
HANA can be easily integrated into the existing scenarios, but this does not necessarily mean that you are using it to the fullest of its capabilities. So if one has invested so heavily in HANA then its better that the customers change the 'programming' paradigm (Hardware changes are minimal except HANA H/W)
e)HANA is your unfair advantage.
HANA lets you be many steps ahead of your competition who are not on HANA. You can follow link given by Tao, In SCN also you can find many success stories about customers implementing HANA.
f)Code is pushed to HANA
The task of Logic building is pushed down to HANA. So the logic for user request is computed at DB level and only relevent data for the user request is passed to Application Layer for dispaying in the proper format.
g)SAP has plans to make the DB layer for every Solution as HANA. This is the shift phase is SAP's strategy where only a few BW, CRM, APO etc. solutions are available for implementing on HANA. The vision is to make every SAP System run on HANA. When on HANA and optimized for running on HANA, the programs can work faster, no data redundancy(ideally), simplified landscape, maintainance and easy management of licenses.
h)ABAP: Syntax-No change + New features for accessing HANA models. Paradigm: Total Shift in paradigm as HANA will be made to compute the logic instead of Application Layer.
i)Role of ABAP programmer-A copy paste of Teo's Answer 🙂
Just so that you understand importance of HANA in ABAP. Now to be certified ABAP programmer on Netweaver 7.4, one needs to go through the HA100, HA300(Totally HANA) and HA400(ABAP Part of it).
--
Shreepad Patil