Over the next few weeks, I will be providing an introduction (or reintroduction) to SAP HANA. I’ll begin today by exploring some of the background on how SAP HANA came to be and how it is different from what other vendors are offering. In subsequent pieces, I will dig a little deeper into this core differentiation and provide some real-world examples of how businesses are transforming themselves with HANA.
It is hardly news that major changes are afoot in the database world. When SAP introduced the HANA in-memory platform in 2011, it kicked off a firestorm of activity among conventional database vendors. Each of the major players has updated, or at least announced planned changes to, its long-established data management solution set. IBM DB2 now offers BLU Acceleration to provide an in-memory boost for analytics workloads. Microsoft SQL Server 2014 includes an in-memory option; Oracle has announced a similar option for 12C . Even Teradata has come to the table with Intelligent Memory, which allows users to keep the most active parts of their data warehouses in memory. Why the sudden interest in in-memory? It would appear that everyone is following SAP’s lead.
But appearances can be deceiving. These vendors have introduced in-memory capability to accelerate analytics performance in a conventional environment, one where multiple copies of the data are scattered throughout the organization. Unsurprisingly, they have long encouraged this model. (After all, selling all those database licenses is good for business.) By contrast, with HANA, SAP has introduced a new paradigm for real-time computing: a single copy of the data, without the need for aggregates or special indexing, support for all transactional and analytical workloads and use cases. A HANA environment is never slowed down by the need to pre-arrange the data using traditional database techniques, the tricks and workarounds that the conventional database vendors have evolved over time in an attempt to keep performance in line with data growth and ad hoc access.
In developing these solutions and bringing them to the market, these vendors are attempting to answer an important question: “How can we reduce data latency?” This is a question that SAP took on some time ago. Through the years, we have achieved dramatic progress in reducing the impact of the I/O (input /output) bottleneck between application (or analysis) and disk with such innovations as the Advanced Planning Optimizer and SAP LiveCache. This work culminated in 2005 with the introduction of SAP Business Warehouse Accelerator, which leveraged dual-core chips and in-memory processing to provide exponentially faster performance for SAP Netweaver Business Warehouse environments.
Having addressed the question with nearly a decade ago that the conventional database vendors are only now contending, at SAP we have turned our attention away from fixing yesterday’s problems. With the advent of multicore chips and more broadly and inexpensively available RAM, we began to ask what tomorrow’s data management environment might look like. As a result, we came up with a new, and much more daring, question:
“How do we enable the transition to real-time business?”
Built into the question that the database vendors are asking is the assumption that the core paradigm will remain the same. Some data will be in memory; some data will be on disk. To improve performance, you change the balance of power between those two fundamental facts of existence. And any time you need to do anything new with the data, you just make another copy of the database. But our question makes no such assumptions, which has enabled some radically new thinking about what kind of changes can be made.
Let’s simplify things. Vastly. Let’s move the entire database into RAM, cutting the disk and all those disk access issues and delays out of the picture. And let’s run the entire enterprise — all applications, all transactions, all analysis, — on that single, blindingly fast, always up-to-date database.
Such a solution can provide businesses real-time analytical and transactional processing — something that has been long needed, but that has not been possible at the scale required to support the full enterprise. This model eliminates the need to distinguish between transactional and analytical data, as well as the need to populate the organization with multiple copies of the same data. All of the work cycles and resources dedicated to maintaining those multiple copies and keeping them in sync with each other? Gone. Moreover, this model does away with the need for a separate application server. A single live instance of the database replaces all that former complexity.
SAP HANA is about more than just a new kind of database, although a series of fundamental shifts in database technology are involved: the columnar data architecture means that the data is pre-optimized for any query without indexes or aggregates; on-the-fly materialization means that there is no need to spend time and resources creating, updating, and replacing a smaller, “digestible” subset of the data; multi-temperature data management means that non-active data can be seamlessly identified and moved to the appropriate storage. Nor is the new model just about the performance, although HANA delivers exponentially greater performance than any technology that has come before. Ultimately, it is about the introduction of a whole new way to do enterprise computing.
Along the same lines, it is not accurate to say that the other players have followed SAP’s example with their own “in-memory” solutions. It is absolutely correct to speculate as to whether new entrants in this space can compete with SAP (rather than the other way around.) But in so speculating, we have to remember that each of their solutions is firmly grounded in the old paradigm. They are not asking how to move business to real time; they are still trying to answer yesterday’s questions. Or to be fair, perhaps they have come up with a new question to ask:
“How can we (claim to) offer the same thing SAP has?”
