In-Depth

Q&A: Super-Charging OLAP Performance

HyperRoll says it can squeeze out the most performance from your existing investments in Oracle and Hyperion Solutions OLAP platforms without investing in more processing power or storage.

• By Stephen Swoyer
• 01/14/2004

If you thought OLAP was a mature technology that’s immune from marketplace shocks, you’d better think again. HyperRoll Inc., whose products are used to massively scale BI solutions, says current OLAP solutions have effectively solved one problem—query response—even as they’ve ignored an equally pressing one: cube load times.

We spoke with Rich Ghiossi, vice president of marketing for HyperRoll, about how customers can squeeze plenty of improvement out of their existing investments in OLAP platforms from Hyperion Solutions Corp. and Oracle Corp.

Compared to a BI market segment such as enterprise reporting, the OLAP space is relatively sleepy. Why do you feel there’s an opportunity for a product like HyperRoll, which complements (and delivers performance enhancements) on top of conventional OLAP servers such as Essbase and Oracle Express/9i?

In some ways, we’re still trying to solve the same issues [in OLAP] that we were working on five years ago. We’ve been able to deliver information quicker, we’ve been able to put it in data warehouses more efficiently, we’ve been able to cleanse the data quicker, but we’re still struggling with the same issues. What’s needed is a significant improvement in performance. I’m not talking about something that’s 100 percent faster. I’m talking about 10, 20, or 30 times faster. HyperRoll is at last getting that for the OLAP in the marketplace.

I know that benchmarks don’t tell the whole story, but we’ve just seen a round of OLAP benchmarks in which both Oracle and Hyperion have ostensibly demonstrated the kind of significant improvement you’re talking about. Oracle, for example, claims that it’s current OLAP server platform is 75 times faster than Hyperion’s flagship product from 1999, or five years ago.

It’s funny you should mention that, because these benchmarks are typically designed to do just one thing: measure query performance. The build time of the cube is not calculated. What they do calculate is only the incremental build time. But anything that’s related to cube build times, those are the issues that influence query performance problems—but that’s not being reflected at all in the [now defunct OLAP Council’s APB-1] benchmark.

It gets back to what I was saying earlier—that OLAP really solves the response-time issue, but hasn’t solved the load issue and really hasn’t solved the issue of the amount of information that you can get into a cube environment. The way that customers are solving that problem is by adding increasing amounts of storage and processing power.

And HyperRoll has a better way?

Based on the efficiency of our product, [customers] don’t need to buy additional processing power, and because of the way we store our data, in a kind of highly compressed format, there’s no requirement to add storage. We can come in and say, "Don’t make these hardware purchases [for more storage and processing power]. Instead redirect these funds, implement this software server, and we’ll be able to support your needs for the next two to three years."

How about a description of how you’re able to do this?

What we do is we take the definition of the dimension that’s in Express or Essbase and we actually take that and load that into our environment, and we’re able to kind of load information from the existing databases in a way that is completely transparent to the applications and the users of those applications.

Once the data’s loaded into our high performance aggregation engine, then users can start using the application just like they were using that before, when in fact the original cube is empty and they’re just bypassing it and going directly into HyperRoll. HyperRoll provides answers from a query performance standpoint, at the same kind of performance they were used to in their existing environment, but they can have a lot of information in more dimensions.

What kinds of performance improvements are you able to deliver for customers?

We’re delivering the kind of significant improvement that I talked about earlier. For one of our financial customers, HyperRoll dramatically changed the way that their company was able to close their books and do their analysis, from 18 hours down to 30 minutes. We were able to solve the load window issue for starters, but because of the dramatic performance they’re getting from reducing their load windows, they were able to add back more data into the cube, so they can do more analysis as well. We have more than 30 customers, many of which are Fortune 500 companies.

You say that you’re designed to work with Oracle Express and Hyperion Essbase. Is HyperRoll effectively abstracted from users of these products, so that they’re not going to notice any disruptions or changes?

Because we sit behind existing OLAP environments, we implement into these environments for the most part transparently to users. This is really key. This is what allows us to enhance an existing environment. We say, 'We’ll take this piece of software technology and insert it into the existing environment and allow you to enhance the performance without having to train your users, put in a new application, or anything else."

Any thoughts to extend support for HyperRoll to other OLAP platforms, such as Microsoft’s Analysis Services or to Applix, among others?

It’s a discussion that we have constantly, and it’s still open in terms of what we’re going to do. But what we find is that the bigger problems, the larger volumes of data, tend to be in the Essbase and Express environments, and that’s where we shine. If you’ve got a really small environment and you don’t care when the data’s going to be available, which historically is where Analysis Services has played, chances are you won’t be interested in our product.

As Analysis Services continues to mature, and as it increasingly gets used in these large environments, we’d certainly consider it. As for supporting other OLAP servers, for now, we plan to stay very focused on Essbase and Express.