Hana 3, what else?
![[shutterstock.com: 80454427, Vira Mylyan-Monastyrska]](https://e3mag.com/wp-content/uploads/2020/04/shutterstock_80454427.jpg)
It is well known that Hana was not built for the cloud. But what's the problem? The E-3 article "We are ERP" by author "no/name" from E-3 February 2020 hits the nail on the head: the operating costs of Hana as a Service for SAP itself.
A database that automatically adapts to the load would be the optimal solution. This would allow operating costs to be kept 100% within the optimum range and no resources to be wasted.
The desire for infinite scalability is obvious and understandable. Is it feasible? That is the other side of the coin. An anecdote from SAP: "We need disruptive solutions, so develop them.
Go, go!" So you're supposed to invent something unprecedented on demand, implement it quickly and shift the laws of physics along the way. That's difficult, isn't it?
Hana 3 touches a physical boundary in exactly this way. For the required infinite scaling, the tasks must (a) be divisible into infinitely small parts, (b) be executed in parallel and - so that it is still a database - (c) still retain a global sequence/transactionality. This is not possible. The internal contradiction of the requirements must be resolved via a compromise in at least one place.
Effort and goal
But if infinite scaling is just a way to reduce costs, maybe there is a cheaper way? This has been tried before, Hana admins know it as a multi-database container (MDC).
The index server, the process that takes care of all data processing and data storage in Hana, was identified as the problem.
In the cloud data center, each Hana requires one of these large index server processes. So how about installing just one Hana instance per server and having independent database containers for it?
So development has removed everything from the index server that does not belong to a database and moved it to the name server: data storage? No, that's not possible, that's the core of the database.
The queries? The session management? In the end, nothing could be removed. Result: The SystemDB plus one index server per database container runs on each computer. Savings? Practically zero.
The index server
How could you make the index server smaller instead? At the moment it is 4 GB with an empty database.
It has an SQL engine, a calc engine, spatial queries, time series and graph queries, document store. The cheap method would be to remove parts of the functionalities.
However, one of the advantages of Hana is its universality. This is rightly written on every marketing slide. The index server would therefore have to be cut up differently somehow, obviously into a small core functionality and a dynamic, load-dependent component.
One of Hasso Plattner's key statements ten years ago was that a data record is created once and queried hundreds of times. From this, Plattner concluded that a database should be optimized for query speed and that insert performance is of secondary importance.
The entire Hana database and S/4 Hana are built around this premise, which is why they are so successful.
For our index server, this means throwing out all code that deals with querying data. Really everything! The responsibility of the index server is thus reduced to data management and the implementation of data changes.
The process therefore owns the RAM with the data and handles the insert, update and delete statements. The index server would only be the in-memory storage level.
Queries are the complex part with the query optimizer, the various engines and the high risk of having a bug. Read-only access to the RAM of the index server (shared memory) is sufficient for these functions and they can work completely independently of each other.
Another advantage of this approach: What happens today when a user submits a query and the code runs amok because of a bug? The index server crashes and with it the entire database.
If the query is a separate process, perhaps even each currently running query would run in a separate process, only the one user session collapses.
However, designing this query process well is not easy.
Container
What would that look like in practice? Each customer has a Docker image with Hana. This image is started on a server with the purchased performance data. Since the index server is now so small, it can be started very quickly, so quickly that most developer instances can even go into a hibernation state and the Docker image is stopped when inactive.
If a customer needs more resources, their Hana instance is stopped and restarted on the other hardware. Or you can go in the direction of scale-out, start several Docker instances on the same database files and these distribute the data among themselves.
Where a container runs, in the cloud data center or at the customer's premises, makes no difference.
What I have described so far is general knowledge from database construction. It will be exciting to see what technical foundation Hana Cloud gets.
Conclusion: old versus new
If the Hana Cloud were a normal version of Hana, SAP would have already gained a lot. The in-memory data is located at the top level and, thanks to the Hana Native Storage Extensions (NSE), a lot of data can remain on disk. The whole thing should be packaged in containers for easier handling of the many instances. However, this only seems to be the plan to a limited extent. The aforementioned separation of Hana Cloud development into a separate, second code line has consequences.
In any case, two code lines mean double the development costs - or one of them is neglected. In addition, all existing Hana features have to be re-implemented, and as this is not possible in the short time available, some will be missing. In turn, the features for effective cloud operation can only be found in the Hana Cloud code line.
Satisfied customers are not to be expected. As an on-prem Hana customer, you can see the further developments relating to database operation, but you cannot use them yourself. Cloud users will miss features that have long been available on on-prem Hana but have not yet been implemented in the cloud codeline.
As long as this situation only lasts for a short time, it can be dealt with. However, I have not yet heard any statements that indicate a convergence of these two developments, on the contrary.
