- SAP is telling customers that they can use data tiering in HANA to use an innovation in database design.
- How accurate is SAP data tiering being new?
SAP has communicated a new item for SAP HANA. It is an amazing technological breakthrough where the data is processed in the computer’s memory, but then written to the disk for something called “persistence.”
See our references for this article and related articles at this link.
We cover this amazing development in this article.
Let us begin by reviewing the quotes from SAP.
“SAP HANA native storage extension is a general-purpose, built-in warm data store in SAP HANA that lets you manage less-frequently accessed data without fully loading it into memory. It integrates disk-based or flash-drive based database technology with the SAP HANA in-memory database for an improved price-performance ratio.”
This is amazing.
Translated for the laymen, it means that with SAP’s super-advanced technology enables companies to use both memory and disks and even flash drives in something called a “server.”
We have a top secret image shown below. These photos of a prototype of the device used by HANA were smuggled out of SAP at high risk to our agents.
The server is a piece of hardware that has the memory, the disk drives, and the flash drives inside of a metal box.
But the story gets even better. Some of the data does not need to be accessed all of the time. This is what SAP calls “warm data.” Let us review the SAP explanation of this new data classification.
“Between hot and cold is “warm” data — which is less frequently accessed than hot data and has relaxed performance constraints. Warm data need not reside continuously in SAP HANA memory, but is still managed as a unified part of the SAP HANA database — transactionally consistent with hot data, and participating in SAP HANA backup and system replication operations, and is stored in lower cost disk-backed columnar stores within SAP HANA. Warm data is primarily used to store mostly read-only data that need not be accessed frequently.”
While undoubtedly impressive, it is different from SAP’s earlier statements about HANA, where HANA was to be better than all other databases because all of the data was to be loaded into memory. And through shrinking the database size, you could…
“Run an ERP system off of a smartphone.”
In an article published in 2013, John Appleby stated…
“HANA was the only in-memory database with full HA.”
The SAP HANA Native Storage Extension?
SAP calls this SAP HANA Native Storage Extension. However, it is actually nothing. It is merely a restatement of what all the competing databases have been doing for decades.
Its called memory optimization.
Let us look at SAP’s graphic, where they describe their contraption.
We congratulate SAP on this observation.
What is described above is a standard memory-optimized database. The same design used by other database vendors decades ago and still used to this day. Without being able to load data into memory, it would be impossible to perform a calculation or any type of processing. This can be tested by taking any computer or server and removing the memory modules and then rebooting the computer or server. But according to SAP, this design is perfect for replacing “legacy databases,” as the following quotation attests.
“The Perfect Architecture to Replace Legacy DBMS Technologies
SAP has a general sizing guidance for HOT vs. WARM data ratio and Buffer Cache size. However, it is ultimately the application performance SLA that drives the decisions on HOT vs. WARM data ratio and Native Storage Extension Buffer Cache size.
For the hardware to implement Native Storage Extension, simply add necessary disk capacity to accommodate WARM data and memory to accommodate Buffer Cache requirements as per the SAP sizing guidance.
The combination of full in-memory HOT data for mission-critical operations complemented by less frequently accessed WARM data is the perfect and simple architecture to replace legacy DBMS technologies. This also eliminates the need for legacy DBMS add-on in-memory buffer accelerators for OLAP read-only operations requiring painful configuration and management.”
But now the question arises,
“If SAP has such a similar design to other databases, why are those databases legacy?”
To this, we have the answer. But before we get to that, we would like to take this opportunity to introduce our innovation.
Introduction the Brightwork Piston Gas/Diesel System
This diagram describes something we have named a “piston.” It comes in two types, an energy source we call “gas” and a second which uses something called “diesel.” Our proprietary design deploys a four-stroke design, which is as follows, Intake, Compression, Combustion, and Exhaust. (Patent pending, so please respect our IP)
We are thinking of deploying this technology in some type of propulsion system.
Stay tuned for more details!
SAP’s warm data tiering is nothing new. Furthermore, it contradicts everything SAP said about HANA years ago. HANA is now increasingly backtracking on earlier pronouncements that were designed to make it appear different from other databases.
From the beginning of HANA’s introduction as a product, SAP was told you could not place everything in memory. SAP told everyone that they did not “understand” and that with their proprietary technology, they had achieved zero latency because of their extraordinary ability to manage memory in a way that Oracle or Teradata and others could not. This meant loading all data into memory with zero swappings. We had to investigate the HANA documentation to find it was actually memory optimized, and SAP lied about this.
SAP is not an all-in-memory database, nor has it ever been.
SAP receives a Golden Pinocchio Award for making something that all databases have sound innovative.