ABAP_to_the_Future

15
ABAP Programming for SAP HANA
age space for the indexes was almost as bi g as for the whole table itself. In addition,
the SAP Basis department had to spend a lot of time each month reorganizing
indexes that became fragmented over time.
To use an analogy, consider a book about monsters, and the chapters are organized
from least scary type of monsters to the scariest. If you know the scariness
level you desire, you can jump straight to the correct chapter. However, if you
want to know about green monsters, you either have to flick through the whole
book looking for the word “green” (a full table scan) or use the index at the back
of the book, look up the word “green” there, and then look at the pages the index
recommends. However, if suddenly you were able to read a book at 10 million
billion words per second, then you could flick through the book and find all the
green monsters in no time at all. Yo u wouldn’t need the index, so the book
wouldn’t need the index, so the book could be 5% shorter. In other words:
Removing indexes means that you need less database space.
SAP HANA can read the database table bookat such a high speed because it’s very
different from the traditional databases you’re used to, not least because it’s column
based as opposed to row based. This means that you do not need indexes at
all anymore; it’s as if you’ve manually created an index on every field, but without
any of the drawbacks just mentioned.
Of course, everything has a caveat. If you read the standard SAP documentation,
then you will see SAP hedging its bets and saying that secondary indexes are usually
not required. That was a bit wooly, so I went hunting and found this quote
from SAP expert John Appleby (for more details, see the “Recommended Reading”
box at the end of this chapter):
In certain obscure scenarios where you find a performance problem, a secondary
index can help. This is only in OLTP sc enarios, where you have complex joins and
only return a small subset of data from the table.
Ninety-nine percent of scenarios will neve r benefit from an index. They take up
space and will slow insert operations, so should be avoided.
What practical implication does this have on your actual database table design?
You will find when you create a data base table in SE11 that a new tab has
appeared: DB-Specific Properties (Figure 15.11). Here, you can see that the
default setting for the new table is for column-based storage inside the database,
as opposed to the row-based storage that was always the case in the past.
694