Capping IT Off

Capping IT Off

OLAP databases are being killed by In-Memory solutions

In early 90s, to provide acceptable performance results during reporting and drilling, many vendors have designed OLAP (On-Line Analytical Process) solutions. When standard relational databases store detailed data in classic row-column storage, OLAP tools allow to store pre-aggregate results and thanks to a hash-function provide a direct access to many results. Tools like Cognos Powerplay, Hyperion ESSbase, and Microsoft SQL Server OLAP have created a new growing market.

To model a cube, it is mandatory to define KPIs (Key Performance Indicators) and dimensions. This restriction has been a strong (and hidden) quality. Business Intelligence, Data Warehouses were new words, modeling a data mart was not yet standardized. So using an OLAP product was also a good way to model simply the business needs and implement it quickly, with high successful results.

Due to the fantastic user-friendly interfaces and the price of those solutions, these tools have been mostly adopted by the management. I still remember the impact of the fantastic Cognos Powerplay web interface in 1998. Financial functionalities (eg. planning or budgeting) have often been added by this vendors and this is also why there is a strong installed OLAP tools.

But in years 2000s, the original motivation to go to OLAP (performance) became an issue. Well modeled and sized relational databases were able to provide same kind of performance results than OLAP cubes. But feeding an OLAP cube needs to launch a batch that becomes more and more difficult to fit in the batch window. It is important to understand that with data growth, OLAP computing delay became more and more an issue.

And because the "OLAP" word had a positive image, it became a market trend with many versions, 3 of them are the most important to be known:

  • Real multidimensional cubes are called M-OLAP (Multidimensional OLAP). MOLAP tools are typically Cognos Powerplay, Hyperion ESSbase, Microsoft SSAS, SAS/MDDB, Oracle Express, …
  • Star schemas modeled on relational databases are called R-OLAP (Relational OLAP). This is typically SAP BW, Microstrategy, …
  • Using relational databases for detailed level and multidimensional cubes for aggregated plans are called H-OLAP (Hybrid OLAP). Most MOLAP tools allow this way of storage.
But technically, the interest has practically vanished. The user OLAP analytic tool is often a fantastic and very easy to use tool, but it was possible to have the same tool accessing to a relational database with the same functionalities. The planning functionalities are easier to develop when connected to a relational database, because OLAP cubes have not been designed for transactional or frequent data updates.

in-memory

Currently, In September 2011, MOLAP solutions are still here because:

  • The based installation is large and often used by critical processes,
  • When a very complex KPI (consolidation results, gross margin on industrial process ...) is needed, relational databases are not able to provide a good performance, or will need a very complex and custom development using many materialized views. This is the main reason for me to recommend an OLAP tool in enterprise BI/EPM architecture.
But in memory analytic solutions are able to solve this last point. In memory analytic tools like Qlikview allow making part of the planning/budget functions in a very easy way. Solutions like IBM TM-One simulates an OLAP cube, but store the full content in memory to allow complex computing with very high performance results.

Storing the full database in memory (or at least the star schema) using SAP HANA or just adding lot of RAM on classic databases (Oracle or DB2 servers with 1 TB of memory change radically the way the database works) is fast enough to guarantee complex KPI calculations in a few seconds maximum. And in this case, it is no more needed to replicate data or to compute an OLAP cube, so it helps delivering real-time BI.

In this future market, two major companies look very well placed:

  • SAP. Even if HANA is not yet fully ready for this function, it is clear in 2012 SAP will propose business functions (like planning, treasure management, inventory management …) that will use HANA to deliver new and high business value.
  • Oracle is about to propose in-memory solutions (based on Oracle TimesTen product) linked to Exadata. As ESSbase owner, it will be easy to manage the move from installed base to this new target.
Other vendors are active too:
  • IBM is proposing in memory OLAP functionalities through its TM-One product. Even if I’m waiting for the next version to really integrate C10 platform and adapt its current look & feel to the current century.
  • Qliktech. The in memory Qlikview product is a good way to answer quickly to many analysts needs and provides also (limited) planning and budgeting capabilities.
  • Kognitio is a database vendor with a performance strategy based on their in-memory caching capability. Please note most of Kognitio projects are deployed as a service (Kognitio cloud)
  • Microsoft. I was disappointed by Microsoft when they have launched Performance Point because they came in a new market with no innovation. Because SSAS is maybe the most used OLAP tool, Microsoft has to react, and I would be surprised if this company has got no reaction to the in-memory wave.
This market will be very active during the 5 next years. But there is something important I have not said yet. Currently, many OLAP tools just provide what is needed. If it works well and delivers the right business needs, why do you want to change the tool?

About the author

Manuel Sevilla
14 Comments Leave a comment
jheizenb's picture
Hi Manuel, what is your opinion about Microsoft Powerpivot as an in memory product using the most used BI tool (excel) as frontend?
I saw also that some small vendors are trying to take this wave. Just read an article on SYMTRAX with a product named Starquery who provide in-memory : http://goo.gl/nwEJC
msevilla's picture
Good point Stephen, Federator tools use also more and more in memory capabilities to improve performance and make federation possible. OBI EE uses also this functionality. I really think in memory can be used on every step of Information usage :)
msevilla's picture
I consider PowerPivot as a local cache. When PowerPivot requests some data from SSAS to fill an Excel spreadsheet, the user is able to work locally with no connectivity with the DB. The concept is very good, similar than Qlikview, Tableau Software or Tibco Spotfire. And it is through Excel => Fantastic. But there is a big default on PowerPivot. While Tableau, Tibco and Qliktech technologies have the same engine on the server and on the client, the local Excel engine is not the SSAS engine. It means local agregations may provide different results when connected than when disconnected. I was very surprised when hearing that, especially because it should be technically easy for Microsoft to implement the SSAS engine on Excel. I hope it will change on the next versions, but for now, i consider this as a showstopper !
Manuel,
It seems you been misinformed regarding the PowerPivot system. The exact same engine that runs in PowerPivot for Excel is also available in Analysis Services running as the PowerPivot server in SharePoint. Same bits, same results. 100% compatibility.
Analysis Services supports multiple storage modes. You have the classic MOLAP/ROLAP/HOLAP modes shipped with SSAS since 1999. But in addition, starting with SQL 2008R2, Analysis Services is now also offering the VertiPaq storage engine - a highly compressed in-memory column store. This engine in Analysis Services is the same engine that powers the desktop version of PowerPivot.
Amir Netz (from Microsoft)
msevilla's picture
Thanks Amir for this information about the engien through Sharepoint Services.
I have heard about VertiPaq recently, I will investigate on that. I'm planning a blog on columnar/vectorial storage. :)
Hi Manuel,
This is a very interesting article describing the in-memory advantages.
But I would like to react to your last point. In our experience, (I work for <a href="http://quartetfs.com" rel="nofollow">Quartet FS</a>), we do not always replace an existing tool. Often, the split-second calculation of the complex KPIs drives new usage. For example, one of our clients in the Financial Services is using a complex risk measure (Value at Risk) in the front office while it used to be a back-office reporting metric produced by daily or weekly night batches. Today their traders can anticipate impact of a trade on their risk vs. measuring it post-deal.
Amirhossein (from Quartet FS)
msevilla's picture
You're right Amirhossein, and you give me a very good opportunity to add that in-memory technology is first of all the opportunity of doing things that were not able before and delivery new business value through this new solution. This article was focused on OLAP future (or no future :) ). I will come back soon on in-memory usages. Many business cases to evoke.
Hello Manuel,
Great article...What do you think about SpotFire since it is built on the in memory data architecture
msevilla's picture
Spotfire and Tableau software have more (in my comprehension) a cache-memory usage than an in-memory solution. And they do not replace the OLAP database part but may replace the OLAP analytical tool.
To complete this quick answer, using Tableau/Spotfire over an in-memory solution like SAP HANA (or OBI EE 116 that will have the same kind of interaction used over Oracle in-memory Exalytics solution) is a combination with high perspectives.
And nevertheless, Thanks for your positive comments.
Hmm...Manuel...you are saying that I can use Spotfire in conjunction with with HANA?
msevilla's picture
Technically, Spotfire is able to connect with any SQL database. Of course, because of the nature of SPotfire interface, it needs a fast database. I guess HANA can be a great DB for Spotfire, Yes!
However, currently, only SAP products are certified on HANA (mainly BODS and BO BI4). But I'm aware of a cstomer using Cognos over HANA with no issue, even if no officially supported. I'm sure that thanks to JDBC or ODBC Spotfire (or Tableau, MS SQL 2012 PowerView, OBI EE, ..) is able to do it.
As much as I love them, there is an issue with in-memory solutions: Persistency and horizontal scaling.
It is rather difficult to horizontally scale your memory area across several servers in a farm. (Amirhossein will agree, because I requested their firm to do this previously but cannot be done quite easily)
The addressing of memory is totally different to addressing of disk (which can be shared, i.e. box storage), as memory in current hardware is an integral part of the core, remembering our x86/x64 software is actually based on "Move EAX:EDX" instructions.
However in much the same way, traditional OLAP solutions are giving me a headache on how to resolve the performance issue as well.
This isn't going to get any simpler with Big data / unstructured data coming into more importance.
The challenge for traditional OLAP providers is how to catchup with in-memory gang in terms of speed.
On the otherhand, the challenge for in-memory gang is how will they compete with the traditional providers when all databases are going to be hosted on ever faster SSDs greatly increasing cost/benefits to the paying customer. (some vendors have a vertically integrated hardware/software offering, and it's not hard to see why, so they can't lose when attacked from each angle.)
For now, I recommend the BI vendors to think about workflow issues when using their software. (control of data in / data in / data re-calcs / prioritisation) As it is not good enough to work off the same "batch" mindset of the traditional world. i.e. Assume data coming in isn't going to be correct and re-processing, "delta" back processing is a must. Once that is solved, it's vastly more valuable then the 30s wait time for results retrieval.
msevilla's picture
Jacob,
I agree on most of your points, especially the last one. The issues today are not technical anymore, they're about improving the business solutions of the OLAP tools (not the OLAP databases)

Leave a comment

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