Category Archives for "Columnar Databases"

Which is Faster HANA or Oracle 12C?

What This Article Covers

  • Does SAP Have the Advantage it Says it Does Against All Other Databases?
  • A Recipe for Confusion on HANA vs Oracle: The Commingling of Hardware Speed and Database Design
  • SAP’s Strategy for Locking Out Other Vendors
  • The Real Opportunity with HANA vs Oracle?
  • HANA is Not Expensive?
  • The Great Database Speed Debate
  • The Appleby (Formerly Known as the Hasso) Pivot
  • Is Oracle Monkeying with the S/4 Certification?
  • SAP’s Conflict of Interest in Not Certifying Oracle 12c
  • The Mode Switching of Oracle 12c a New Wrinkle in HANA vs Oracle
  • Dictating the Database to the Customers?
  • SAP’s Interest in Sending the IT Industry Back in Time
  • How the Capabilities of Oracle 12c Change the Conversation on SAP HANA
  • How Much Do You Know About HANA?

Introduction

SAP has promoted HANA has run far faster than any alternative database, and this principally means HANA vs Oracle.

This has been the logic that it has used for why SAP would not port new applications, like S/4 (SAP’s new ERP system) to Oracle. (as Oracle has the largest market share of supporting SAP applications, although SAP also is targeting IBM and SQL Server)

This contention has few independent parties even investigating this issue.

In this article, we will review HANA vs Oracle on the topic of performance.

A Recipe for Confusion on HANA vs Oracle: The Commingling of Hardware Speed and Database Design

One of the confusing aspects of HANA vs Oracle is that two different topics are commingled and communicated as if they are one topic.

  • One is the hardware issue, as SAP HANA requires moving the active database into memory.
  • A second aspect is the database design, which is the column based database.

SAP discusses these two topics as if they are the same subject.

One could say that SAP has done a poor job of explaining the distinction. I don’t think SAP is trying to be clear in this area and is primarily hoping customers are confused.

  • The less clear SAP’s customers are on where the potential benefits are coming from, the more the advantage swings to SAP when it comes to negotiating.
  • The more ability it has to market SAP HANA vs Oracle as a differentiated offering.
  • The more it can position SAP HANA as worthy of a serious price premium.

Something which goes undiscussed by SAP is how SAP HANA is both a technology strategy and a targeted strategy to push Oracle out of SAP accounts.

SAP’s Strategy for Locking Out Other Vendors

This is an extension of a strategy that SAP has used to great effect for decades, but with a slight twist. SAP kept other applications out of its customers by using the ERP system as a queen on the chessboard.

Queen

By declaring that all other SAP applications would integrate better with the queen, SAP’s customers could have lower risk implementations.

This strategy has been enormously successful, even after most vendors have come very close to SAP’s integration with their adapters.

One-Time horizontal competition — i.e., competition at the application layer. HANA is a twist on this block out strategy but takes it to the database layer. This is why SAP is so strongly positioning HANA vs Oracle. It is essentially preventing Oracle from competing with S/4 by not certifying Oracle’s database. Even though there is no reason that Oracle, IBM and SQL Server cannot fully support S/4HANA. 

The logic of the stored procedures placed into HANA is a cover for the fact that SAP is using S/4HANA’s exclusive certification to drive HANA sales.

The Real Opportunity with HANA vs Oracle?

It has been proposed to me that the real chance with HANA is for the company to place ERP and all other SAP applications on HANA. Then the analytics engine can sit right on the same hardware. And now no integration or transformation is necessary, and now analytics reports right off of the application tables.

Cognitive

However, wait one second. I know that is feeling mighty big in its britches after over five years of breathless conferences about the brave new world of analytics, and the new Big Data and overall analysts obsession (which has lead to far fewer benefits than originally proposed). However, are we now going to transform all of the hardware to be optimized for analytics?

  • Also, what about non-SAP applications? They won’t sit on HANA, so they do have to be integrated and transformed.
  • Will SAP now make the argument that those applications are legacy because they don’t sit on the “strategic platform” for the company?

Secondly, using HANA is expensive. Even more expensive than HANA vs Oracle.

HANA is Not Expensive?

Hasso Plattner has routinely argued that SAP HANA is not expensive. Typically Hasso Plattner will use the example of compression that is available in column-based databases to reduce the footprint. If you talk to SAP account executives, they will tell you that SAP HANA is expensive. Furthermore, they will inform you that HANA is very hard to position for this reason, once the price tag comes back, the customer balks.

It is a simple thing for Hasso Plattner to propose in interviews how SAP HANA could in some hypothetical sense be not too expensive. But all other sources point to HANA being quite expensive. And you will not be buying HANA from Hasso but an SAP account executive. Hasso’s accuracy lately has been off, and I don’t see analysts or the traditional IT media outlets recording this inaccuracy or commenting upon it. I have performed a detailed analysis of Hasso’s statements on HANA.

For example, Hasso proposed that companies are needed to move to S/4 Simple Finance (now just S/4 Finance). As I outlined in the article Getting Clear on S/4 HANA Terminology, SAP has missed its release date on the rest of the ERP suite, and its actual release date is unknown. Purchasing S/4 Finance, what is now a stranded application would have been a bad move.

After years of S/4 hype, S/4 can’t be realistically purchased (unless you count an immature stand-alone S/4 Finance as “realistic”) even if companies wanted to. 

The Fastest Database in the West (HANA vs Oracle)?

There is evidence building that HANA is not the speed champion that SAP says that it is. One of the primary performance weaknesses of HANA is very rarely addressed. HANA as a column based database is not the correct database design for non-analytic applications. SAP has said that it is, but this is from the computer science perspective, not true.

Although SAP obscures the fact that HANA cannot be 100% column oriented in design.

As I pointed out in the article Where HANA Gets it’s Speed, for inserts, deletes or updates — which what a transactions processing system does all the time, the column based table is slower than the row based.

Row-oriented databases are what is known as the relational database, but which is a row-based database.

The Great Database Speed Debate

John Soat is a writer that works for Oracle, and like Hasso is not an independent source on this topic. However, John’s article in Forbes makes some good points on the topic of HANA vs Oracle. One that stuck out was SAP’s demurring on releasing HANA performance benchmarks for transaction processing.

“..SAP has not published a single benchmark result for any of its transaction processing applications running on HANA. Why Not?”

And I would say it is quite obvious why not. And that is for transaction processing systems like ERP systems these benchmarks won’t be particularly fast.

Vinnie Mirchandani, who is an independent source of the SAP HANA/Oracle 12C debate, in his book SAP Nation 2.0 reinforces John Soat’s point on benchmarks.

“It has not helped matters that SAP has been opaque about HANA benchmarks. For two decades, its SD benchmark, which measures SAP customer order lines processed in its Sales and Distribution (SD) module, has been the gold standard for measuring new hardware and software infrastructure. It has not released those metrics using a HANA database.”

Misdirection from John Appleby

Is it possible that SAP performed the benchmarking but it was poor, so it simply stopped reporting the result?

John Appleby, the Global Head of HANA at Bluefin Consulting and a well known HANA advocate and someone who has provided an enormous amount of false information about HANA has this to say about the topic — which is also documented in SAP Nation 2.0.

“The answer for the SAP Business Suite is simple right now: you have to scale-up. This advice might change in the future, but even an 8-socket 6TB system will fit 95% of SAP customers, and the biggest Business Suite installations in the world can fit in a SGI 32-socket with 24TB — and that is before considering Simple Finance or Data Aging, both of which decrease memory footprint dramatically.”

I can’t tell if this is in direct response to the lack of transparency on transaction benchmarks, but if it is, it is an inadequate response. In fact, it looks to me that John Appleby is changing the topic in his answer.

The Appleby (Formerly Known as the Hasso) Pivot

The question is related to a performance of a transaction processing system on HANA vs Oracle, and John Appleby quickly moves to a discussion of how much companies should only buy more hardware and not worry about it. What is John Appleby talking about here?

He states that “for the SAP Business Suite.” and then goes on to declare the answer for this suite.

Well, the only part of the SAP Business Suite that is ready for HANA is S/4 Finance. There is lots of debate as to how implementable S/4 Finance is. Secondly, the rest of the suite, now called SAP HANA Enterprise Management, as I stated, is not available for purchase. John Appleby is phrasing his response to what should be the future tense as if it is the present tense.

Is it, in fact, critical to scale up for something that does not yet exist?

Is Oracle Monkeying with the S/4 Certification?

John Soat also points out that while Oracle performed very well on one particular benchmark, but SAP will not certify the result as SAP states that Oracle manipulated the test.

Now I was not at the trial, so I am in no position to say what Oracle did or did not do. Oracle has their story, and SAP has theirs. John Soat has a good explanation of each side’s position in his article.

Also Stephan Kohler, an Oracle performance database consultant had the following to say on this topic.

“SAP already answered why they do not accept the benchmark results (you also find this in the mentioned article – Copy & Paste: “Oracle manipulated its BW-EML benchmark by using a custom setup involving database functions known as triggers and materialized views that can lead to hard-to-spot data inconsistencies and aren’t supported in real-world production environments.”). The reason was the use of triggers and materialized views, which are supposed to be not supported. However if SAP would have checked their own SAPnotes – you can see that it is clearly supported and also used in SAP ECO Space. SAPnote #105047: “Materialized Views – Use permitted.

For more information, see SAP Note 741478.” SAPnote #105047: “Trigger – Use permitted as part of the SAP standard system (for example, BW trigger /BI0/05* in accordance with SAP Note 449891, incremental conversion ICNV). Use of Logon Trigger permitted in accordance with SAP Note 712777. Implicit use as part of Oracle features permitted (for example, online reorganisation, materialized views, GridControl/Enterprise Manager). Use in connection with materialized views in an SAP BW system is permitted as long as no flat cubes are available as an alternative. There is no SAP Integration and SAP does not offer support for this.” Flat cubes are available in Beta since Q1/2016 – so nothing relevant to the Oracle benchmark from 2015.”

And this leads to the next topic, and it is a big one.

SAP’s Conflict of Interest in Not Certifying Oracle 12c

The issue that SAP now completes with all of the hardware vendors places SAP in a conflict of interest when certifying databases; this is a conflict of interest that before its investment into HANA it did not have. What was once a straightforward process is now rife with political intrigue where one now has to parse the statements by SAP and Oracle to see who is telling the truth.

How can SAP certify Oracle, that is give them a fair hearing, if, by certifying Oracle, SAP cut’s into their market share for HANA?

The Mode Switching of Oracle 12c, a New Wrinkle in HANA vs Oracle

Oracle 12c can switch between “modes” displaying either in memory rows or memory columns. That is a serious advantage. IBM BLU has a similar ability. Although there is not that much evidence that there is a major need for a database that does both OLTP and OLAP — and it may not be feasible to design one that does each type of database processing equally well. In fact, the trend in databases is the opposite of this, with specialized database designs such as NoSQL, indexing databases flourishing.

However, getting back to the HANA versus Oracle 12c discussion:

  • Oracle’s flexible design should beat SAP HANA in performance for all but pure analytic applications. 
  • The logic presented by SAP that the entire database should be columnar never made sense because few tables are used in analytics. Therefore does it make sense to use analytics-optimized tables (the columnar design) for every single application table?
  • There is a debate as to how mature Oracle’s in-memory database is. SAP lists 7,000 SAP HANA customers. However, most of these customers are known to either not use the software at all (i.e., it is shelf-ware) or to be test systems, not live systems. As a consequence, SAP HANA skills are still quite hard to find.

Furthermore, Oracle’s in memory modal switch adds to the price of Oracle 12c both in license and in maintenance.

Conclusion

With Oracle 12c, Oracle 12c can switch between row based and column based tables and switch for the same table, which is a new capability.

As far as I can tell, just about all of the SAP marketing documentation on HANA has preceded this development. If I were heading up HANA marketing at SAP, I would not want to address Oracle 12c, because I would not have a good answer for it. This is because Oracle 12c undermines lots of effort expended on the part of SAP to get SAP customers to think that SAP HANA technology is unique to SAP to position SAP HANA as unique and better.

The new capabilities of Oracle 12c undermine some SAP contentions that have been proposed over the years. SAP has not addressed Oracle 12c, and most of the material created on SAP HANA was developed before Oracle 12c was released. IBM and MS SQL Server have similar column store capabilities. Not because there was a big reason to develop them, but because SAP, through its enormous marketing placed the focus on this type of database functionality.

First, SAP now does not have a good reason — or should I say a good idea if it puts its customer’s interests first, to only port new SAP applications (like S/4) to SAP HANA.

Dictating the Database to the Customers?

The previous argument that only SAP could provide a fast enough database is most likely untrue. It was always a poor argument because regardless of the reason. No application vendor should be dictating the data layer to its customers. However, repeatedly that is what SAP has said that it wants to do.

“SAP still believes in running the new system in the cloud and on premise, but it will be only SAP S/4HANA with which we can achieve this in one software version going forward. This will reduce the TCO and speed up the so much needed step into the future. Every single application area like data entry, standard reporting, analytics and predictions, the digital boardroom or the multi-channel customer interaction, to name a few, becomes a world class component  in its own right. This alone is a reason to consider an earlier migration to SAP S/4HANA.” – Hasso Plattner

SAP’s Interest in Sending the IT Industry Back in Time

At the Computer History Museum in Mountain View, there is an exhibit that explains that at one time the software was proprietary to the hardware vendor. At that point software was not an “industry,” and a program released by IBM could only run on IBM hardware. The software was not charged for separately, so there was no competition at the software level.

The software industry we know it today only came into its own after it was decoupled from the hardware. And this was only done by the threat of the US enforcing anti-trust legislation against the proprietary software model and hardware vendors. HANA as a coupling between the applications and database layer — controlled by a single vendor, takes us back in time.

This creates what amounts to a proprietary application/database combination.

  • SAP’s argument that only column based databases have a future is also untrue.
  • Finally, unsurprisingly to those who know the database vendors and their history, the idea that only SAP can develop a high-performance database that meets the speed capabilities of HANA is untrue.

SAP’s argument has not been that they are simply the equal of every other database vendor. With HANA they are superior to every other database vendor. That, of course, includes HANA vs Oracle or anyone else for that matter.

SAP certainly can and will keep selling HANA vs Oracle. But the exclusivity argument that SAP has been proposing is no longer a possible position to believe.

HANA & S/4HANA Question Box

  • Interested in Independent Information on S/4HANA & HANA?

    Have you noticed thatnnearly all the published information on HANA and S/4HANA is put out by entities with an incentive to promote S/4HANA & HANA?

    • We can be used to answer a specific question.
    • We can provide more details on existing research or to perform new research.

    If you have an interest in hiring us to obtain independent research or consulting, just fill out the form below.

    100% Privacy Guarantee: We don't share your contact details with anyone.

References

http://www.forbes.com/sites/oracle/2015/12/18/oracle-challenges-sap-on-in-memory-database-claims/

https://en.wikipedia.org/wiki/Proprietary_software

Is ERP on HANA a Major Advantage for ERP Systems?

What This Article Covers

  • Is There an Actual Advantage to Using ERP on HANA with ERP Systems?
  • How Much Do You Know About HANA?
  • Our Work on HANA

HANA ERP

Introduction

Anyone in the SAP space has heard of SAP S/4HANA, which is SAP’s ERP on HANA. S/4HANA has been presented as hugely advantageous by SAP.

However, is this true?

A Major Advantage for Using with ERP Systems?

Column based databases like HANA are not an advantage when the database in question is supporting an application like an ERP system, or any other transaction processing system.

This is because transaction-processing systems tend to access all of the fields in a row. However, when the application in question is analytical in nature, technically known as OLAP, then the database design/table configuration is a disadvantage because the typical query only accesses a few of the fields or columns in a table.

This is explained well in this paper from Oracle on the topic of their 12c product, which is another in memory database.

Oracle Database has traditionally stored data in a row format. In a row format database, each new transaction or record stored in the database is represented as a new row in a table. That row is made up of multiple columns, with each column representing a different attribute about that record. A row format is ideal for online transaction systems, as it allows quick access to all of the columns in a record since all of the data for a given record are kept together in-memory and on-storage. A column format database stores each of the attributes about a transaction or record in a separate column structure. A column format is ideal for analytics, as it allows for faster data retrieval when only a few columns are selected but the query accesses a large portion of the data set. But what happens when a DML operation (insert, update or delete) occurs on each format? A row format is incredibly efficient for processing DML as it manipulates an entire record in one operation i.e. insert a row, update a row or delete a row. A column format is not so efficient at processing row-wise DML: In order to insert or delete a single record in a column format all of the columnar structures in the table must be changed.

This points out that for inserts, deletes or updates — which a transactions processing system — like an ERP system — does all the time. The column based table is slower than the row based — or what is known as the relational database (although using the term relational to differentiate row based on column based databases is not technically accurate as they are both relational databases — the distinction is the format and type of tables used)

However getting back to the main point of this section, ERP on HANA will not speed the processing of ERP systems for most of what ERP systems do. This is Oracle’s point in this quotation from John Soat.

“SAP has not published a single benchmark result for any of its transaction processing applications running on HANA.”

I agree with John Soat, in that there is a very reasonable explanation why SAP does not publish this…because the benchmarks are not impressive.

Conclusion

Columnar databases are a disadvantage for ERP systems or any transactional processing system. That is what makes SAP’s statements about SAP entirely inaccurate. Secondly, in any ERP system, data can be aggregated and updated to just a few hundred tables. These tables can be made columnar — while the rest of the database stays as row based (or as is known as relational). This is the design deployed by Oracle 12C and it calls into big issue the design used by ERP on HANA. Details on this plan are available at this article

These tables can be made columnar — while the rest of the database stays as row based (or as is known as relational). This is the design deployed by Oracle 12c and it calls into big issue the design used by SAP for ERP on HANA. Details on this plan are available at this article Which is Faster, HANA or Oracle 12C?

How Much Do You Know About HANA?

SAP HANA Quiz

This quiz will ask basic questions around SAP HANA.

Our Work on HANA

We are the most prominent research entity that tells the real story HANA and S/4HANA. Both Forrester and Gartner take money from SAP, and Forrester created a false research report on how HANA reduces TCO in return for money. Companies like IBM, Deloitte, and Accenture have mindlessly repeated all of the SAP marketing talking points on HANA and S/4HANA have encouraged their customers to only accept HANA and S/4HANA so they can get the implementation business.

  • Are you a company interested the actual performance benefit from HANA and S/4HANA?
  • Do you need pricing and accurate database sizing for HANA for costing purposes?
  • Are you interested in accessing unbiased and deep research on HANA and S/4HANA for your company?

For more information fill out the form at the end of this page.

References

I cover how to interpret risk for IT projects in the following book.

The Risk Estimation Book

 

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.

Chapters

Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model

Risk Estimation and Calculation

Risk Estimation and Calculation

See our free project risk estimators that are available per application. The provide a method of risk analysis that is not available from other sources.

project_software_risk

Why SAP HANA Database is Actually a Relational Database

What This Article Covers

  • The SAP HANA Database is Often Described as a Columnar Database, but What is This?
  • What is the HANA Architecture for How Data is Stored in the SAP HANA Database
  • The Name Table
  • Why Columnar Databases are Still Considered Mysterious
  • SAP Many Lot of Statements About the SAP HANA database Being Lower Maintenance than What SAP HANA Replaces
  • Which of These Statements is True?
  • Understanding SAP’s Statements About Reducing Unruly Table Growth
  • What is the Accuracy SAP’s Communicated HANA Architecture?
  • How Much Do You Know About HANA?

Relational

Introduction

SAP has given a strange storyline to their HANA database, and as a consequence, there are a great many misunderstood topics on the SAP HANA database. One of the greatest is that SAP HANA database is somehow not a relational database.

To explain why this is not the case we will get into the HANA architecture. That topic is what this article will focus on.

HANA Architecture Changes in Hardware, Changes in Query Capability and Changes in Table Structures with the SAP HANA Database

The changes to the data storage structure are that data can be stored in columns rather than as “rows.” This is often stated in the literature on the topic, but it is not normally clear why this is the case. In fact, at first glance, it appears that it should be the opposite. A columnar database still has rows, but each row is only one field. It is perhaps more accurate to say that the data can be stored in columns, that would look a bit like this.

Tom, Jason, Julie, Stan, Jack, Jack, Blake, Fred, Rebecca, etc..

The Name Table

There are several flaws in the conventional explanation of columnar databases, which explain why columnar databases are still considered mysterious to many people that consume the messaging on this topic. It is also why often the hype appears to overshadow the understanding of this subject.

Several of these flaws have been described up to this point, but a third flaw in the standard explanation is that columnar databases are not the opposite of or set to replace relationally (or should I say row based) databases. In fact, a columnar database is as relational as a row based database. Because a columnar database still has tables pointing to other tables.

Therefore it is not like a Big Data database like NoSQL.

Maintenance

Database Maintenance Issues

Relational databases can take a lot of maintenance, which is part of the role of a database administrator. Tables often have custom columns added to them, which makes each table less efficient for a variety of tasks.

Using Specialized Structures Build for Analytics

The disadvantage of standard relational databases for analysis has been known since analytical applications have been in use, and have been addressed at various points in the history of database design with data cubes.

Data cubes pre-build relationships. And which are run from specialized or not standard relational databases, as well as star schemas, which allow queries to be performed on a dedicated data structure where a predefined combination of tables is used within a standard relational database.

The Use of Data Cubes

Data cubes have been utilized for a long time to speed the ability to retrieve data.

Data cubes do have more overhead, and HANA architecture or a column based on memory database generally, can have many advantages over cubes, in addition to requiring much less IT overhead, and reports development is a major bottleneck in most companies.

Once queries can be changed, this means how that how data is stored needs to change to leverage this shift.

HANA Architecture and Reducing Unruly Table Growth

Another benefit of columnar databases is that they do not lead to the unruly growth of tables. As was previously noted, many analytical tables have 100 or even 200 columns. This is because new attributes are added to existing tables over time. As each column is added, queries slow. The more columns that are added, the more time it takes the database to find any one field as it must scan the entire row. Therefore table growth does directly lead to slower database queries. This is why the columnar database scales so much better than the row based design. Each new column is added to its table.

However, it should be understood that this does increase the number of tables in the database, and the relationships that have to be created. Although because of less redundancy, the total amount of data that is stored is lower.

For instance, if we take the example of color, if a color is not recorded at one point, and then recorded and added to the database, rows may often increase in number as what was once aggregated to a universal color is now broken into multiple colors that apply to that record.

This greatly depends upon the details, but several scenarios are possible.

Other Areas of Maintenance

As tables grow in columns, they require more maintenance. Row-based or what is known as relational databases do require more indexes and do have other overhead. Some of this overhead is reduced with column based databases. However, other types of maintenance increase with column based databases.

Secondly, the column-based database has far less history on which to base support claims. This is because there are so few column based databases in use. But maintenance is not necessarily lower simply because of the HANA architecture. There are other factors at play.

  • Column-based databases also have far fewer people trained in how to work with them, so the similar metaphors would apply to purchasing a car that very few people own.
  • Few mechanics who work on that car will mean higher cost and lower availability of the required skills.
  • Overall, much more data is required before anything substantial can be said about the maintenance costs of column-based databases. And this is not the only question.

What is the Accuracy SAP’s Communicated HANA Architecture?

When HANA was introduced and for several years after SAP gave a distinct impression that the HANA architecture was 100% column-based. However, after several years it was communicated that many of HANA’s tables were row-oriented.

Conclusion

Columnar databases are relational databases as are row-based databases. A better explanation would be to call databases that store mixed data in single tables that are not organized as non-relational, but even that can be a confusing topic.

Relationships still exist with a columnar database, and in fact, there are more of them because there are now more “tables” that are each table being a column.

The SAP HANA is most definitely a relational database design.

SAP’s statements regarding lower maintenance on the SAP HANA database are most undoubtedly unproven, and while SAP can point to some technical support improvements, it is mostly guesswork. The SAP HANA architecture, as with any columnar databases has some areas that are lower in maintenance than traditional databases. But other areas are higher in maintenance.

Secondly, SAP HANA is quite new and has much less history behind it than other databases likes Oracle 12C or other alternatives. Therefore it would be very premature to conclude that the SAP HANA database is lower in maintenance than alternatives.

How Much Do You Know About HANA?

SAP HANA Quiz

This quiz will ask basic questions around SAP HANA.

HANA & S/4HANA Question Box

  • Interested in Independent Information on S/4HANA & HANA?

    Have you noticed thatnnearly all the published information on HANA and S/4HANA is put out by entities with an incentive to promote S/4HANA & HANA?

    • We can be used to answer a specific question.
    • We can provide more details on existing research or to perform new research.

    If you have an interest in hiring us to obtain independent research or consulting, just fill out the form below.

    100% Privacy Guarantee: We don't share your contact details with anyone.

References

I cover how to interpret risk for IT projects in the following book.

The Risk Estimation Book

 

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.

Chapters

Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model

Risk Estimation and Calculation

Risk Estimation and Calculation

See our free project risk estimators that are available per application. The provide a method of risk analysis that is not available from other sources.

project_software_risk

What Performance Improves with SAP HANA and the Columnar Database?

What This Article Covers

  • What is HANA and is it Unique Generally
  • Whether the HANA Technology is Unique to SAP?
  • Understanding the Columnar Database
  • The Specific Advantages of SAP HANA and Columnar Database
  • What Improves with SAP HANA and Columnar Database?
  • How Much Do You Know About HANA?
  • Our Work on SAP HANA

Performance

Introduction

HANA is often represented by SAP as if it’s underlying technologies are unique to SAP, or they were invented by SAP. Repeatedly terms like “innovation” have been applied by SAP to HANA.

SAP has presented HANA as so unique that customers should be prepared only to run the new ERP system — S/4HANA on HANA, and that S/4HANA will not ever be ported to any other database platform. As the vast majority of SAP ERP systems currently run on Oracle, that is quite a bold stance.

SAP’s Proposed Reasons for Its Position

SAP proposes that the reason for taking this position is the following:

  • No other database vendor can match SAP’s performance.
  • SAP has moved code — called stored procedures — into the HANA database, and by implication, that the application is now tied to the database.
  • SAP has been more obscure about other applications outside of ERP, but SAP desired state is only to replace other databases with HANA so that it’s applications and its databases are tied at the hip.

What is HANA and Is the Technology Unique to SAP?

What is HANA? Well, HANA is a columnar oriented database. But what SAP does not explain is that all the other major database vendors have some similar design available. In fact, columnar databases have been in existence since the 1970s. What changed was that the price and capacity of random access memory or solid-state memory had improved so significantly that the database design can now be better leveraged. Interestingly with Oracle 12c, a competitive database can not only match HANA in analytics, but it can switch between row based and column based tables and change for the same table.

Now that SAP has a competitive product with Oracle’s database, the issue of SAP not issuing the certification to Oracle has arisen, something that is explained in the article Which is Faster, HANA or Oracle 12C?

Columnar databases have their advantages. However, they are not universal benefits. SAP HANA is presented by SAP as a universally advantageous combination of database design combined with faster memory/storage. The less one knows about databases, the more this seems credible.

What Improves with the Columnar Database?

While it is true that a columnar database is a radically different a row-based table database, and the differences do not stop at the configuration of the tables – it also means the use of fewer indexes. This is a positive development for database cost because building indexes for analytical purposes is a source of overhead and rework for companies that use standard relational databases for analytics.

This means that by breaking the table into one file per column, the database stored in random access memory or solid-state memory can access only the fields that are part of the query.

Now queries that only pull two fields, perform much faster than queries that pull four areas. And this example has been when a table contains ten fields or columns. However, tables much larger than this are very common.

It is not at all uncommon to find tables with 100 fields/columns. On average, a query will have between 3 to 5 fields/columns.

An Important Lesson on SAP HANA Benefits

As I explained in this previous article titled Has SAP’s Relentless HANA Push Paid Off?, I brought up the fact that SAP has redirected its marketing efforts to focus to a very significant degree on SAP HANA

SAP HANA does not benefit every business function equally, because not all functions of activity are a bottleneck due to speed limitations, and SAP HANA does not work the same way regarding its speed for every application.

  • To understand the benefits of SAP HANA, as well as its limitations, it is necessary to get into the computer science of what makes up SAP HANA.
  • A solution like SAP HANA allows businesses to do things that it could not do before, so some forecasting or projection is required to fully leverage SAP HANA because merely doing the same things one is currently doing faster is not where the opportunities with SAP HANA lay.

Conclusion

A columnar database like SAP HANA is not at all new. Most of what I have written above was true decades ago. However, the difference is that columnar databases have a particular advantage when used with memory versus disks. This is due to how the media is read, and it turns out that a database with “narrow” tables — (the narrowest being 1 column) combined with that database being stored in memory makes for very fast retrieval. However, this is an analytics purpose. And not all computational functions are analytical.

While all data actions improve with faster hardware, specific actions are better or worse depending on the type of action taken. Therefore, it should be specified that the column based database is only optimized for the data retrieval action.

HANA’s underlying technologies — in-memory databases and the column-based database (as opposed to the row based) were not invented by SAP, and the techniques are not unique to SAP.

  1. It is incorrect to propose columnar databases as a newer design since both columnar and row-based databases have been around for about the same amount of time — it is merely that columnar databases were never accessible or attractive.
  2. With the ability to use more significant amounts of memory, columnar databases, or emulated columnar databases have begun to receive more attention, but outside of SAP, this attention has been almost entirely for use in analytics. SAP is the only software vendor that proposes that columnar databases are better for all applications.

Below is a video that explains columnar databases. You will note that the presenter is a professor and does not use the term HANA anywhere in his explanation.

How Much Do You Know About HANA?

HANA & S/4HANA Question Box

  • Interested in Independent Information on S/4HANA & HANA?

    Have you noticed thatnnearly all the published information on HANA and S/4HANA is put out by entities with an incentive to promote S/4HANA & HANA?

    • We can be used to answer a specific question.
    • We can provide more details on existing research or to perform new research.

    If you have an interest in hiring us to obtain independent research or consulting, just fill out the form below.

    100% Privacy Guarantee: We don't share your contact details with anyone.

References

I cover how to interpret risk for IT projects in the following book.

The Risk Estimation Book

 

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.

Chapters

Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model

Risk Estimation and Calculation

Risk Estimation and Calculation

See our free project risk estimators that are available per application. The provide a method of risk analysis that is not available from other sources.

project_software_risk