Yes, In-Memory Tech Is a Lot of Hype. But You Can Profit From It.

A few years ago, executives at SAP AG decided to make a very big bet on in-memory technology as a competitive differentiator. The logic went something like this: customers want faster applications, and a data-management system that leverages main memory for storage (rather than a “traditional” database system, which stores data on persistent media) is more than capable of delivering that necessary speed.

Row of Racks in a DatacenterDriven by that thinking, SAP has integrated its proprietary in-memory technology (known as HANA, which stands for “High-Performance Analytic Appliance”) into much of its software portfolio over the past several quarters. The company claims that HANA will boost the speed of business-intelligence applications to near real-time, delivering crucial insights that allow clients to react faster than ever to the twists and turns of the market. Even as some customers adopt a wait-and-see attitude, SAP has doubled down again, and again, and again on the technology’s future.

Click here to find database jobs.

By mid-2013—roughly three years after HANA’s launch—SAP could claim that 1,500 corporate customers used its in-memory products, earning the company hundreds of millions of dollars per year. The strategy, it seemed, had begun to succeed.

Success, however, draws competitors. Oracle, at last year’s edition of its OpenWorld conference in San Francisco, announced the Oracle Database In-Memory option, designed to accelerate database-driven processes. Oracle executives claimed their product included a new in-memory column-store format, the better to speed up analytics processing and data warehousing. With his typical penchant for sweeping announcements, Oracle CEO Larry Ellison announced that customers using the software would have the ability to scan data “at a rate of billions or tens of billions of rows per second.”

If that wasn’t enough, Microsoft recently announced, as part of its new SQL Server 2014, the introduction of the In-Memory OLTP memory-optimized database engine. At least on paper, In-Memory OLTP can deliver significant improvements, particularly with short-running transactions.

While SAP had a bit of a head start in the in-memory wars, and boasts the development and marketing resources to keep a regularly updated product in front of potential buyers, Oracle and Microsoft pose significant challenges to HANA’s rise. For starters, many thousands of businesses rely on Microsoft’s SQL Server to support IT infrastructure—that’s quite a built-in audience for In-Memory OLTP, should Microsoft begin to aggressively market that option. Oracle also takes considerable pleasure in cross-selling products to its existing user base, which means it could quickly scale up the presence of its Database In-Memory tool. (And don’t forget IBM, which is developing its own in-memory options, including DB2 BLU.)

In addition, dozens of small-scale IT vendors have their own in-memory products, which could appeal to startups and nascent businesses without the cash to spend on an enterprise platform.

All of which brings us to the following points:

Do Businesses Need In-Memory Technology?

Businesses that need to process massive amounts of data in as short a time as possible could have a need for in-memory database technology, yes. Take a retailer that sells custom-built scooters to clients all over the world; by employing an in-memory option, that retailer could speed up the time required to plot deliveries or generate reports based on dynamically updated data. That being said, platforms such as HANA are an expense, and so any business will need to weigh whether the cash outlay is worth the extra seconds, minutes, and hours potentially saved by speeding up business-intelligence processes.

Is There a Demand for Experts?

As with any software area in which SAP, Oracle, Microsoft, IBM, and a host of smaller companies are all participants, there’s an attendant need for experts who can walk companies through their options with regard to implementation and execution—and whether they’ll need in-memory technology at all, despite the hype. Over on Slashdot, Hazelcast Vice President Miko Matsumura has a column detailing how “it’s time to cool off the fake benchmarks and rhetoric and think clearly about the most cost-effective approaches to application performance and scalability.”

But There’s a Downside, Right?

Of course—nobody said the tech industry would ever make anything easy, right? Any “generalist” expert in in-memory technology will need an in-depth awareness of the proprietary options out there, from HANA to the SQL and Oracle add-ons. If that wasn’t complicated enough, different in-memory “brands” only work with certain types of applications, whether analytical (business intelligence) or transactional. Clients will also want to know if they’ll need to replace applications and add hardware in order to access the full power of in-memory technology—an answer that could vary, depending on IT vendor.

Where Do I Start?

Fortunately, there’s lots of information about in-memory technology available online, including SAP’s own HANA slide-decks, a massive PDF describing the workings of IBM’s DB2 BLU, and Microsoft’s website devoted to In-Memory OLTP. You can also check out Dice’s own postings on the subject.

Related Stories

Comments

  1. BY Justin Stuparitz says:

    Microsoft has had in-memory OLAP cubes since 2005. This is where most people benefit from–on the read side. Only the largest systems in the world need that kind of performance on the write side (ie OLTP). I have benched marked SQL Server 2014 memory optimized tables locally on my laptop at 600k transactions/sec and Redis at 58k/sec over a 1GB network. There is a huge benefit though for a lot of even small/med size systems on the read side.

Post a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>