[Mondrian] Retrieving child members from cache

Matt Campbell mcampbell at pentaho.com
Wed Oct 29 09:45:23 EDT 2014

I had been thinking about our Range discussions when I was looking at this.  You may have already thought through this problem, but “completeness” of the cached sets has been on my mind.  With both caching of ranges and caching of members in general, it seems like a big challenge is figuring out whether we have the complete set given a context.  With a TupleConstraint in place, level.members (or a range) may be discontinuous, so it could be tricky figuring out whether the cache contains all members needed given a new context.

For example, if there’s a request for Customer.[Name].members with a SqlContextConstraint including [Store].[Store 1], we might end up with a limited and discontinuous set of members, say

{  Customer.[A],  Customer.[C] }

A subsequent request for this range in the context of [Store 2] might then cache a different discontinuous set:

{ Customer.[A],  Customer.[B],  Customer.[D] }

Ideally we’d have a way of merging these two sets, such that requests for single members can be fulfilled.  It would further be useful to know whether the set of level members is complete for a context (do we have all members?), as well as if the range { [A] : [E] } can safely be fulfilled in other contexts.

With both caching of ranges and caching of members in general it seems like we need a way to update a combined cache when new members have been retrieved and insert them in the correct places.  But the real trick seems to be knowing whether we really have the complete set.  Unless the members have ever been retrieved in the context of the DefaultTupleConstraint, I don’t see a simple way to know whether we have all of them.

From: mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org] On Behalf Of Luc Boudreau
Sent: Tuesday, October 28, 2014 4:14 PM
To: Mondrian developer mailing list
Subject: Re: [Mondrian] Retrieving child members from cache

This is a similar problem than what I'm facing while trying to optimize ranges of members in the cache. We use a hash to represent entries, while we should use something like a TreeSet. The TupleConstraints we have can all be represented in terms of ranges (singletons are a range of 1).

I had looked into the RangeSet class from Guava, but it didn't fit. I haven't had any spare time yet to look into Julian's proposal of using the TreeSet, but am planning to do it soon. Let me know if you find something useful before I do.


On Tue, Oct 28, 2014 at 3:36 PM, Matt Campbell <mcampbell at pentaho.com<mailto:mcampbell at pentaho.com>> wrote:

When a query like

  SELECT Customer.[Name].members on 0 from [Sales]

is executed, MemberCacheHelper will helpfully cache the set of members from the [Name] level.  Subsequent queries which require loading level.members can skip the SQL query and grab from cache.  Very good.

If, however, the subsequent MDX is for specific members of that level, e.g.

  SELECT {[Customer].[Customers].[USA].[OR].[Portland].[Jade Brandberry],
          [Customer].[Customers].[USA].[OR].[Portland].[James Solano]} on 0 from [Sales]

then each Customer member will be retrieved individually via separate SQL queries and cached, using the its corresponding ChildByNameConstraint in the key.

Given that we have already loaded these members, intuitively it seems like we should be able to find them in the level member cache and avoid the redundant SQL queries.  Finding the members in cache, however, is complicated by the fact that caching uses the TupleConstraint as part of the key, so it’s not obvious which (if any) item in the cache might actually contain the referenced member.

Have others thought about how we might improve member retrieval for enumerated sets?

Mondrian mailing list
Mondrian at pentaho.org<mailto:Mondrian at pentaho.org>

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

More information about the Mondrian mailing list