SAP HANA: Developers Perspective

By | April 23, 2016

Developers perspective of SAP HANA

how HANA can reduce the development complexity and big bang for the buck :

 In-memory

  • Faster access to data which is predominantly stored in-memory rather than on disk with the use of buffers with limited space for only very frequently accessed data as is with traditional databases…
  • Columnar stored tables
    • Optimal storage of tables in columns which allows for faster access and dictionary encoding – both together achieve significant compression of the data. The factor to which compression is achieved depends on the context of data too – e.g a different compression algorithm can be applied to each table depending on type of data it contains, the number of distinct values it might have etc (6 different types of compression methods done by HANA to my knowledge)
  • Row store also exists in HANA for unstructured data amongst other things
  • CPU processing & network capabilities
    • More powerful processing speeds can be achieved today – 2 billion records scanned per second per CPU core etc.
    • 10 Gbit/second
  • Embedded XS engine in DB
    • This is a game changer that allows for development and aggregations to be done right in the database (which used to otherwise be considered a black box with all development of stored procedures being done on application level)
    • This results in faster math and only the end result (trimmed down) needs to be sent to the application rather than all the data before aggregation is applied (think this addresses your comments – reduces complexity and extremely data intensive processing)

 Another point is the development of the runtime objects / HANA models or views directly in HANA.

These are essentially allowing you to connect master data tables together with joins, unions, star schema for flattening hierarchies etc. in order to implement your business logic for meaningful reporting–then applying the data intensive aggregation to the DB layer instead of in the application layer as would be the case with legacy DB’s–Avoiding the movement of large data sets – just what the calling app / user actually needs

Leave a Reply

Your email address will not be published. Required fields are marked *


*