[Mondrian] MongOLAP

Julian Hyde julianhyde at gmail.com
Mon Nov 18 14:06:09 EST 2013

I see that Pentaho have quietly merged the MongOLAP branch into Lagunitas [ https://github.com/pentaho/mondrian/pull/194 ].  The purpose, I presume, is to allow Mondrian to access MongoDB, but this code change just adds SPIs to make that possible. Pentaho have not, at this point, checked in the code to access MongoDB.

This significant increase in the surface area of Mondrian’s SPIs, and those SPIs will need to be maintained going forward. So, I think that the community should have been consulted on this change.

In my opinion, generalizing Mondrian’s internal data interfaces to non-relational data, and then exposing them as ‘public’ SPIs, is wrong-headed. These internal data interfaces are old, complicated, and have serious issues. I have been trying to remove them, and while this change basically cements them in place.

Technically, the right approach for Mondrian to access non-SQL and hybrid data is to use a translation layer, with a limited amount of state for caching, that uses extended relational algebra as its common language. Optiq is such a translation layer, it has several adapters including one for MongoDB, and I encourage both Pentaho and the community to try it out. 

I recently created a simple mechanism where a Mondrian model can contain multiple data sources, and each of those data sources may be traditional JDBC or a non-SQL data source such as MongoDB or Splunk, or in fact any data source that implements Optiq’s Schema SPI. This code is in Mondrian’s federate branch [ https://github.com/pentaho/mondrian/tree/federate ]. I encourage the community to try out this exciting new functionality, and I urge Pentaho to reconsider its wrong-headed approach to MongoDB support.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20131118/fc7bc16d/attachment.html 

More information about the Mondrian mailing list