Explain SAP HANA In-Memory Computing Fundamentals in SAP

41 / 65

HANA DBbeginner

SAP HANA In-Memory Computing Fundamentals

The architectural principles that make HANA fundamentally different from traditional disk-based relational databases.

HANA keeps the primary copy of the data in RAM. Disk is used for durability — savepoints and the log — not for normal reading and writing.

A disk-based database is like a librarian who must walk to a distant archive stacks room and fetch each book individually; HANA is like having the entire library's contents already photographically memorized and mentally indexed, so any question about any book's contents - including ones spanning thousands of books at once - gets answered instantly without a single trip to the shelves.

Key Concepts

That is not "a database with a big cache". A cached database still assumes the data lives on disk and plans around that. HANA assumes it does not.

Why it matters, in numbers.

    RAM access          ~100 nanoseconds
    SSD read            ~100 microseconds     1,000x slower
    spinning disk seek  ~10 milliseconds    100,000x slower

Traditional database design — indexes, buffer pools, careful access paths — is largely about avoiding disk reads. Remove the disk from the read path and much of that machinery stops being necessary, which is why HANA needs far fewer indexes than the databases it replaced.

Column store by default. A row store keeps a whole row together; a column store keeps each column together.

    row store     [1|Asha|IN|1000] [2|Ravi|IN|2000] [3|Meera|UK|1500]
    column store  ids: [1,2,3]  names: [Asha,Ravi,Meera]
                  country: [IN,IN,UK]  amount: [1000,2000,1500]

SELECT SUM(amount) on the row store reads every field of every row to extract one. On the column store it reads one contiguous array and ignores the rest.

SELECT SUM(amount)

Dictionary encoding is where the compression comes from. Each distinct value is stored once, and the column holds small integers pointing at it:

    country column:  IN, IN, UK, IN, US, IN, UK ...
    dictionary:      0=IN  1=UK  2=US
    stored:          0, 0, 1, 0, 2, 0, 1

Business data is full of repetition — status codes, countries, material groups — so this compresses enormously. Ten to one is ordinary.

And the compression makes it faster, not just smaller. Filtering country = 'IN' compares integers against 0, not strings. Less memory is read, and comparisons are cheaper. The data often never needs decompressing at all.

country = 'IN'

Then parallelism on top. Work is spread across many cores, and SIMD instructions apply one operation to many values at once — which is possible precisely because a column is a dense array of same-typed values.

Row store still exists, for small tables written constantly where whole rows are read, mostly system and metadata tables. It is a specific exception, not a choice you make often.

Why this matters beyond HANA itself. The Universal Journal, embedded analytics and code pushdown all depend on aggregating large volumes on demand rather than maintaining pre-computed totals.

None of them were practical on a disk-based row store, which is why HANA is described as an enabling technology rather than a faster component — the applications above it were redesigned around what it makes possible.

What the interviewer is probing.1. "Why is columnar storage faster for analytics?" Probing: the mechanism. Stalls: "It is in memory." Moves up: only the needed columns are read, compression ratios are far higher, and aggregation works on contiguous values — memory alone is not the answer.

2. "What is the delta merge?" Probing: the write path. Stalls: "Compaction." Moves up: writes go to an uncompressed delta store and are periodically merged into the compressed main store, which is why write-heavy tables need monitoring.

3. "Is HANA only an analytics database?" Probing: the positioning. Stalls: "Yes." *Moves up:* no — it runs transactions and analytics on the same tables, which is what removes the separate reporting copy.

4. "What is the durability story if it is in memory?" Probing: the obvious concern. Stalls: "It can lose data." Moves up: a redo log written synchronously on commit plus periodic savepoints to disk, so a restart replays rather than loses.