Reporting against in-memory ERP data vs standalone BI

Submitted on: Wed, 04.02.2014 11:03pm - Gary Owen |

 

I recently had an interesting exchange with a customer on the pros and cons of reporting against in-memory ERP data vs standalone business intelligence (BI) solutions.

There are a few ERP packages out there that keep their entire database in-memory rather than storing things on disk. This allows you to query directly against the transactional database instead of building a traditional data warehouse or any analytic hypercubes.

Some of the smaller ERP packages employ this strategy as a way to get around runtime performance problems associated with reporting against live data. As to be expected, ERP architects usually optimize their database design for transactional processing. Unfortunately databases designed for transactional processing are often poor structures for analytical reporting. This is what has given rise to the OLAP vs. OLTP (on line analytical processing vs. on line transaction processing) realm of research. In-memory databases for reporting are an attempt to solve both problems by moving all of the databases into RAM.

I’ve started to see declining interest in this approach since solid state drives (SSDs) have become more affordable. SSDs are able to get most of the benefit of putting data in RAM (e.g., improved random read times) without the drawbacks of an in-memory database (e.g., significant data loss or corruption when the server crashes or the power goes out and battery backups fail).

While the goal of the in-memory ERP system is to try and approach the speeds possible with an optimized OLAP tool like MITS, this approach is kind of a blunt object. By throwing massive amounts of hardware at the problem we hope it will go away.

I’d be interested in your thoughts on this topic. What do you see as the pros and cons?