Capping IT Off

Capping IT Off

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

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.


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
4 Comments Leave a comment
Manuel, I know your article is now a bit old but there is a fundamental point where I don't agree and I'm curious to have your opinion: mixing the storage question and the semantic question. Whether you store and index your data on disk or in memory you will still need a way to formalise the semantics and the OLAP paradigm is at the same time very general (which ensures expressivity) and very strict (which ensures quality). You can think about replacing it with another formalism (graph for instance) but you still need the formalism which is independent from the storage technology. Would you agree? Walter
msevilla's picture
Walter, This post is focused on OLAP storage. Using KPIs and dimensions (OLAP semantics) is of course a real way to make the link between IT and business (thru design first and thru BI tools usage later). So I guess we have same point of view ;) Manuel
Indeed then but I would reword the thread as in-memory storage benefitting all BI semantics. :)
msevilla's picture
In my mind, OLAP databases is clear enough. And as may know, changing a post content (especially not a simple update a few weeks after, but its title 2 years later) is not recommended ;) By the way, I will post again soon (after a few months of silence) ;)

Leave a comment

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