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 Dadwould 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.