S/4 HANA: ALL ABOUT TABLES
https://www.linkedin.com/pulse/s4-hana-all-tables-james-olcott-mba?trk=hp-feed-article-title-share
In my article “FIRST TWO THINGS I LEARNED ABOUT S/4 HANA” published last month, I made two points about S/4 HANA, the latest upgrade of SAP’s venerable ERP (Enterprise Resource Planning) software system run by a lion’s share of Fortune 1000 companies:
1) HANA today is much more than the powerful in-memory appliance or hardware that SAP rolled out in 2013 and,
2) I tossed out a few details in an offhand manner about improved tables structures.
I am very fond of understatement.
The specific terms used in my article were “rationalized.” And “eliminating redundant fields.” As well as my personal favorite line, “using any attribute as an index within tables.”
So what the hell does that mean exactly? In sixth grade English. (Please).
Today’s article will examine in some greater detail what exactly these database table handling and structural enhancements mean for the SAP user. These are at the heart of the new S/4 HANA system. And will give the reader some insight as to why this is big news for anyone working in and around BIG DATA.
1. COLUMNAR DATABASE
The first point to explain is the inherent advantage of the new columnar orientation of the HANA database over traditional ones organized in the more familiar rows of records.
Consider, for example, the following database table of employee records consisting of four records organized in rows:
Pretty simple, right? Four records broken down into three data fields each (not including the record number or ID).
In a row oriented database, that data is stored like this:
But in a column oriented database, the data is stored as follows:
Same data, just stored differently. As if it was transposed in an MS Excel spreadsheet. So what’s the big deal?
The columnar database offers a faster way to aggregate – or add up values. Suppose you want to run a common database query to answer the question, “How much are we paying the employees?”
In a row based database, all four records must be read to compute the sum as follows:
In a columnar database, only one read is necessary!
In a database composed of four records, like in my little example, the improved efficiency and performance of the faster aggregation will not be noticeable. But in a database with billions of records, you get the idea. The improved read will be blazingly fast!
So the output speed of the query will be greatly enhanced. But what about input? In this case, it’s the row oriented database that will be faster since the new record inserts as a new row in one fell swoop. Consider the following input example in the two systems, adding new employee Clint:
The columnar database will need to update four separate rows which will take more time. However data input or write speed is not typically an issue in data management. It’s the output, or the read speed, when running queries that matters! You have data for a reason, which is to pull from it. I am sure that most readers here will agree that a lot of time is wasted watching spinners on screens while your custom query is ripping through 4,000,000 rows of data.
I mean, it is possible to have a database that is write sensitive. Suppose you are keeping a table of egregious lies made by US Republican Presidential Candidates. It's probably best to keep that one on a row basis to keep it from getting bogged down due to active inputs.
2. ALL ATTRIBUTES AS INDEXES
So what does it mean to “use any attribute as an index within tables?” This is where it gets really interesting. Suppose you have the above table of employees except, instead of four records, you have 200,000. Let’s add a new fourth field “gender,” where the possible values are “M,” “F,” and “O.” It's 2016, after all, get with the program!
In a row oriented database, the gender attribute “F,” for example, is stored redundantly roughly 100,001 times. That’s a lot of deadweight in terms of storage. Running a query to pull all records where gender is F means that 200,000 rows must interrogated for value “F” in the gender field. Oy vey gevalt! A lot of work for nothing!
In a columnar database, you can simply go to column E and select for all records where the value is “F.” As one of my English clients was fond of saying (when he wasn’t yelling at his IT team), “It ought to be a dawdle.” (That’s Englishspeak meaning it should be easy). And it is!
It’s as if the database – in columnar form – is pre-selected for the convenience of running queries! By design, it’s much more efficient for fetching data. And this is where most time is consumed around Big Data. The time and efficiency savings are very real. My Dad would have been proud!
On top of this, add some proprietary data compression where table and data size is reduced by a factor of five. That’s some kinda diet, right? This means that data hosting costs can be reduced. And because of the smaller size, the whole thing can be kept in memory instead of disk storage. Thus the efficiencies and retrieval speed improvements compound.
SAP, in typical fashion, jargonizes this as “Going Digital,” or, even less helpfully, “Real-Time Enterprise.” They can’t seem to let go of that particular term since the 1970s. But the point is clear – this kind of organization, processing, and compression allows for running complex simulations on an immediate basis as opposed to overnight. Imagine cost allocation and payroll simulations, legendary for reading massive amounts of records, flying along with nearly immediate results instead of slogging through eyeball-deadening spinners for a Sponge Bob-like eternity!
That in-memory appliance mentioned at the top of this article, by the way, is still available to speed things up, from a hardware point of view (with the S/4 HANA software pre-installed). But S/4 HANA is designed to run off databases on any certified hardware platforms using Linux OS. Or in the cloud. You could even use the cloud as an intermediary step in your implementation and then transfer everything back to your local hardware later.
So you have lots of good options.
S/4 HANA is very real. In a variety of ways. As an SAP consultant, I look forward to playing my customer’s favorite tunes on the world’s favorite ERP platform.
My gratitude to Mssrs. Shyam Jajodia of LSI Consulting and Shyam Reganti of 3Core Systems, Inc. for their generous time and assistance to me in writing this article.
