Skip to main content
Pentaho Documentation

Configure Mondrian Engine

The Pentaho Analysis (Mondrian) engine is configurable through a properties file. Mondrian options allow for enhanced engine and data source performance and functionality under certain conditions. Pentaho Analyzer is also configurable, but more in terms of adjusting the functionality of the Analyzer client tool itself.

Manage Analysis Data Sources

In order to use a properly prepared data source with Pentaho Analysis, it must be established in either the User Console as a Native (JDBC) data source, or in your Web application server as a JNDI data source. Whichever method you choose, you will have to know the name of the data source later on when you're asked to supply it in Pentaho Schema Workbench.

Schema Workbench can only work with one data source for each Mondrian schema; this is a structural limitation in the software that will be remedied at a later time. You can have multiple JNDI or Native (JDBC) data sources established, but only one at a time can be used with Schema Workbench.

Edit the Mondrian Properties File

The mondrian.properties file located in the /pentaho/server/pentaho-server/pentaho-solutions/system/mondrian folder. Edit this file to adjust the Mondrian engine for performance and usability within our specific environment.

This section is specific to maximizing Mondrian performance with Pentaho Analyzer. For all available settings, see http://mondrian.pentaho.com/documentation/configuration.php.

Performance

One of the key performance goals for Analyzer is to push as many operations to the database as possible. This is particularly important when querying many high-cardinality dimensions because you want Mondrian to only process the combinations that make sense and not a huge cartesian product which is sparsely populated. Pay particular attention to the following engine properties:

mondrian.expCache.enable=true

Improves the performance of summary numbers such as ranks and running sums.

mondrian.native.crossjoin.enable=true

This is an essential property which enabes pushdown to the database so that Mondrian does not perform large cross joins in memory.

mondrian.native.filter.enable=true

Particularly important for pushdown of Not In and Excludes filters.

mondrian.native.nonempty.enable=true

This should be set to false to optimize Mondrian SQL generation given the MDX patterns generated by Analyzer. Analyzer uses non-empty cross joins to push down joins between high cardinality attributes to the database. If this property is set to false, there are many non-empty cross joins which would get evaluated by Mondrian instead because Mondrian pushes down the individual arguments such as dimension.members.

mondrian.olap.maxConstraints=1000

Used in conjunction with the mondrian.native.ExpandNonNative property. This should be set to as large as the underlying DB can support.

mondrian.native.ExpandNonNative=true

Allows pushdown of even more crossjoins by materializing the crossjoin inputs into IN lists. For example, a crossjoin whose inputs are MDX functions can first have their inputs evaluated to members and then convert the crossjoin into native evaluation.

mondrian.olap.elements.NeedDimensionPrefix=true

Analyzer always generates dimension qualified members so no need to spend time searching for members on different dimensions.

Usability

mondrian.result.limit=5000000

In the event that pushdown cannot occur, this is the largest crossjoin size that Mondrian should try to process. Anything that exceeds this will likely send the CPU for a toss and result in long server hangs. If this limit is hit, Analyzer will present the user a nice warning suggesting options to simplify the report.

mondrian.olap.case.sensitive=true

This is important for "Equals" filters because the UI will preserve the casing of filter values. If the user defines a filter on "John Doe", then the filter should only applies to "John Doe" and not "john doe"

mondrian.olap.ignoreInvalidMembers=true

This is important for saved reports because the user may build a report with a filter on 10 sales rep and after the next ETL, one of them is gone. The report should continue to run and return just the 9 remaining sales reps.

mondrian.olap.ignoreInvalidMembersDuringQuery=true

See mondrian.olap.ignoreInvalidMembers

mondrian.olap.iterationLimit=5000000

Similar to mondrian.result.limit except for controlling limits on aggregate evaluation.

mondrian.olap.compareSiblingsByOrderKey=true

This is required for sorting members in a dimension A->Z or Z->A. This property fixes a bug in Mondrian but was added for backward compatibility.

mondrian.olap.NullDenominatorProducesNull=true

The best way to understand this property is via an example. Suppose you want to see quota attainment for your sales reps which is computed as Booked Deals / Quota. Some reps may not have quotas and so quota attainment is either infinity or null. By treating divide by null as infinity, Mondrian will return these sales reps in the report. Otherwise, if divide by null evaluates to null, then Mondrian will filter those reps out (due to the NON EMPTY).