Inscrivez-vous ou connectez-vous pour rejoindre votre communauté professionnelle.
I will try to explain with my limited technical ability, and I request all other expert to help in correcting or adding to the discussion.
For the past periods, SAP system ran on conventional Database engines. So a transaction saved will pass through from CPU to Memory (RAM) and then to DB (Storage), and vice versa an information reported will pass from DB (Storage) to Memory (RAM) then to CPU for processing.
What SAP HANA do differently in the previous scenario, is that it takes the DB (Storage) to a parallel level to the Memory (RAM) and replicate the complete DB in Memory (This is why it is called In-Memory Computing), so an information (i.e. a Completed Transaction) will be passed to Memory and once it is in Memory it is available to anyone for reporting or further processing it doesn’t have to be retrieved again from DB. But still the Transaction will be stored in the DB as the final storage location.
By doing this, SAP HANA overcomes the slowness in Disk Data transfer (Read and Write in DB) and take advantage of the very fast Memory processing speed (read and write in-memory, and in the same time store permanently in DB without affecting transaction speed of application).
This gives users of SAP HANA the possibility to have real-time access to information (Reporting and analytics) and very fast transaction processing (Background jobs and Reports), theoretically not just for SAP but for any application that will use this technology as a DB of choice. This usually was achieved previously by having2 Databases; one for transaction processing and the other for reporting, HANA combine both in1 DB.
That is a simple answer to a very complex technology which have many more angles worthwhile of further discussion.
