HANA is many things. It is an own, in-memory database manager with columnar store by SAP AG. Including a number of newly-developed components for ERP, advanced planning, Business Intelligence, Analytics, etcetera.

What is special about SAP HANA’s database management system? In an earlier article, the key challenge of designing contemporary database management software has been described. On large data sets it has to work well for both row and column oriented operations. An ERP-application requests many, simple, row oriented read and write operations: request a row, update and store it. An analytics-application requests fewer operations, mostly reading, but on larger data sets. Simplified: the traditional row oriented organization of data is well-suited for Online Transactional Processing (OLTP, like ERP). The column store suits Online Analytical Processing (OLAP, like business intelligence) much better.

This time: Column oriented storage in SAP HANA.

Every table in SAP HANA is either row or column oriented, depending on the database’s design.

All column oriented tables are also made available in row oriented form by SAP HANA. This makes it possible to decide, before execution of any query on request by the user, which is the best way to access the data: via the row store or the column store.

HANA takes care that the row and column oriented versions of a table are kept in sync. The column store is highly compressed usually. Despite that, maintaining two versions of the same table requires extra memory capacity. And for every change to the data in a column oriented table (insert, update, delete), both versions of the table have to be adjusted.

Complicated? Using a column store makes dramatic improvements to the speed of queries on large data sets possible. For example, the number of sales order lines per (material-based) MTP-type.

The MRP-type is a material property that determines how the availability of a material should be planned. In SAP ERP, it is a simple code with usually only a few or a few dozens of possible values. A column store organizes this as a row of (pointers to) materials per possible value of the MRP-type. By doing this, a query that requires “materials per MRP-type” can be executed very quickly.

It gets even more complicated: delta-stores.

HANA is veel dingen. Een eigen, in-memory, database manager van SAP AG met column store faciliteiten. Met daarbij een aantal nieuw-ontwikkelde componenten voor onder andere ERP, geavanceerde planning, Business Intelligence, Analytics, etcetera.

Wat is bijzonder aan de database manager van SAP HANA? In een ander artikel is de uitdaging bij het ontwerp van moderne database management software beschreven. Het moet op grote gegevensverzamelingen goed werken voor zowel rij- als kolom-georienteerde operaties. Een ERP-applicatie vraagt veel, kleine, rij-georienteerde lees- en schrijf-operaties: een rij opvragen, bewerken en opslaan. Een analytics-toepassing vraagt minder operaties, en leest vooral, maar doet dat op grotere gegevensverzamelingen. Simpel gezegd is de row store vooral geschikt voor Online Transactional Processing (OLTP, zoals ERP) en de column store vooral voor Online Analytical Processing (OLAP, zoals business intelligence).

Nu: Kolom-georienteerde opslag in SAP HANA.

In SAP HANA wordt iedere tabel, naar keuze van de ontwerper van de database, ofwel rij- ofwel kolom-georienteerd aangelegd.

Een kolom-georienteerde tabel wordt echter ook beschikbaar gemaakt in rij-georienteerde vorm. Daardoor kan, afhankelijk van de operatie die door een gebruiker wordt gevraagd, voor het uitvoeren worden bepaald wat de beste manier is om de tabel te benaderen: via de rij- of de kolom-versie.

HANA zorgt zelf dat de rij- en kolom-versies van de tabel gelijk blijven lopen. De kolom-versie is vaak sterk gecomprimeerd. Het bijhouden van twee versies van dezelfde tabel kost desondanks extra opslagcapaciteit. En bij iedere mutatie van gegevens in een kolom-georienteerde tabel (toevoegen, wijzigen of verwijderen) moeten beide versies worden bijgewerkt.

Ingewikkeld? De column store maakt spectaculaire versnelling van queries op grote gegevensverzamelingen mogelijk, bijvoorbeeld de aantallen verkooporderregels per (artikel-gebaseerd) MRP-type.

Het MRP-type is een artikeleigenschap die bepaalt hoe de beschikbaarheid van een artikel gepland moet worden. Het is een eenvoudige code in SAP ERP met meestal enkele tot enkele tientallen mogelijke waarden. Een column store slaat dit op als een rijtje (pointers naar) artikelen per mogelijke waarde van het MRP-type. Hierdoor zijn queries die “artikelen per MRP-type” nodig hebben zeer snel uit te voeren.

Het wordt nog ingewikkelder: delta-stores.

HANA is many things. It is an own, in-memory database manager with columnar store by SAP AG. Including a number of newly-developed components for ERP, advanced planning, Business Intelligence, Analytics, etcetera.

What is special about SAP HANA’s database management system? First, a general introduction.

Increasing processor power and larger memory have become available at lower prices over the past years. Operating system software is capable of dealing efficiently with these new capabilities. This makes the concept of performing data intensive tasks in memory increasingly attractive: in-memory computing.

For the in-memory operations, the fastest memory available should preferably be used. A cache on the processor is preferred over the separate RAM. And preferably, the fastest of the caches is used. The fastest cache is usually the smallest, so the use of the different types of memory requires careful consideration for each calculation task.

Another aspect is the component that performs data-intensive calculations. Close to the data it needs to be done, preferably. By the database management software itself. That makes sense but is not in line with the traditional roles of application servers and database servers, in which they exchange a lot of data. Moving the calculation to the database server is called code pushdown.

When calculation tasks on large data sets are performed in-memory, on the database server, it is key that the source data can be requested in an efficient way. For this, it is usually more efficient to request a single table column in its entirety.

The relational model for databases is row oriented, and this is how traditional database management software works. To be able to request a table column, we need a column store. This is a way of storing data so that we have efficient access to parts of the column, or even the full column. Even when it contains millions of items.

A column store increases the efficiency of certain calculations on large data sets considerably. But a large part of the tasks of the database manager will still be row oriented.

This is a key challenge of the design of database management software: on large data sets it has to work well for both row and column oriented operations. An ERP-application requests many, simple, row oriented read and write operations: request a row, update and store it. An analytics-application requests fewer operations, mostly reading, but on larger data sets.

Simplified: the traditional row oriented organization of data is well-suited for Online Transactional Processing (OLTP, like ERP). The column store suits Online Analytical Processing (OLAP, like business intelligence) much better.

Following: how does the column store of SAP HANA work?

HANA is veel dingen. Een eigen, in-memory, database manager van SAP AG met column store faciliteiten. Met daarbij een aantal nieuw-ontwikkelde componenten voor onder andere ERP, geavanceerde planning, Business Intelligence, Analytics, etcetera.

Wat is bijzonder aan de database manager van SAP HANA? Eerst een algemene introductie.

Krachtiger processoren en geheugenchips met grotere opslagcapaciteit zijn de afgelopen jaren telkens tegen lagere prijzen beschikbaar gekomen. Operating system software is in staat om deze nieuwe mogelijkheden effectief te gebruiken. Daarmee wordt het aantrekkelijk om gegevens-intensieve taken geheel in het werkgeheugen uit te voeren: in-memory computing.

Bij in-memory bewerkingen gaat het er om dat de snelste vorm van geheugen wordt gebruikt die beschikbaar is. Liever een cache op de processor zelf dan het separate RAM-werkgeheugen. En bij voorkeur de snelste van de beschikbare caches. De snelste cache is vaak het kleinst, dus het inzetten van de verschillende vormen van geheugen vraagt een zorgvuldige afweging voor iedere berekening.

Een tweede aspect is de plaats waar gegevens-intensieve berekeningen plaatsvinden: bij voorkeur zo dicht mogelijk bij de gegevens. De database management software zelf, dus. Dat klinkt logisch maar past niet goed bij de traditionele rolverdeling tussen applicatieservers en database server die onderling veel gegevens uitwisselen. Het verplaatsen van de berekeningen naar de database server heet code pushdown.

Wanneer we berekeningen op grote gegevensverzamelingen in-memory op de database server kunnen doen, is het belangrijk dat we de brongegevens efficient kunnen opvragen. Het is daarvoor vaak handiger om een hele kolom van een tabel ineens op te vragen.

Het relationele model voor databases is rij-geörienteerd, en dat is hoe traditionele database management software dan ook werkt. Om een hele tabelkolom efficient ineens te kunnen opvragen hebben we een column store nodig. Dit is een techniek om gegevens zodanig op te slaan dat we efficient toegang hebben tot delen van een kolom, of de hele kolom, ook als het om miljoenen gegevens gaat.

Een column store maakt bepaalde berekeningen op grote gegevensverzamelingen aanzienlijk efficienter. Toch zal een flink deel van de taken die de database management software moet uitvoeren nog steeds rij-georienteerd zijn.

Dit is de uitdaging bij het ontwerp van database management software: het moet op grote gegevensverzamelingen goed werken voor zowel rij- als kolom-georienteerde operaties. Een ERP-applicatie vraagt veel, kleine, rij-georienteerde lees- en schrijf-operaties: een rij opvragen, bewerken en opslaan. Een analytics-toepassing vraagt minder operaties, en leest vooral, maar doet dat op grotere gegevensverzamelingen.

Simpel gezegd is de traditionele rij-georienteerde organisatie van gegevens vooral geschikt voor Online Transactional Processing (OLTP, zoals ERP) en de column store vooral voor Online Analytical Processing (OLAP, zoals business intelligence).

Later: hoe werkt de column store in SAP HANA?

In 2016, I registered domain name homan.ee. It matches the way I write my name on a form that requests family name and initials. Top level domain ee is a country code, which, following ISO3166-1, belongs to Estonia. And that is where I have requested the domain name.

Already earlier, I had been looking at this domain name. After the dissolution of the Soviet Union, Estonia has developed quickly, also regarding internet technology. However, registration of domain names in the top level domain ee could only be done by entities established in Estonia until recently. Furthermore, it required a process involving paper work and physical visits to offices in Estonia. A number of interesting developments made it possible for me to register the domain name from my home.

Between 2006 and 2016, Toomas Hendrik Ilves has been the president of the Republic of Estonia. Mr. Ilves was raised in the United States. In 1991, after the new Estonian independence, he became a resident. He was a member of the national and European Parliaments, after which he became president. He launched an ambitious plan to provide governmental services via the internet, large scale. Estonian residents can do a lot with their government issued digital identity: taxes, social security, subsidies, voting, requesting permits, etc.

The digital identity is being exported as well. Non-residents can request Estonian “e-Residency”. And this is what I have done in 2015. After my request had been processed, I was invited to collect the stuff at the Estonian embassy to The Netherlands, located in The Hague. A plastic identity card and a reader to connect to a pc. Similar to a debit card.

The possibilities of e-Residency should not be underestimated. With my digital identity and the reader, I can digitally sign documents. And that gives me a lot of possibilities, for example to open a bank account at an Estonian bank, establish an Estonian Ltd, do VAT-reporting for this Ltd. Maybe even marriage, but I did not check that.

Since 2016 it is also possible to register domain names with extension ee, using the digital identity. Finding a local, affordable hosting solution was not an issue, of course. Everything could be arranged easily from my home.

Estonia has a relatively small population. After the Soviet era stagnation, there was a desire for development. The backlog proved to be an advantage for the realization of modern concepts like the digital identity. And Toomas Hendrik Ilves was the director and producer who made it all possible. Not entirely comparable with the situation in The Netherlands, but still I think we can learn from it.