StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<blockquote> <p>is SegmentHeader.getUniqueID the appropriate key to use in the cache?</p> </blockquote> <p>Yes and no. The UUID is convenient on systems like memcached, where everything boils down to a key/value match. If you use the UUID, you'll need to implement supportsRichIndex() as false. The reason for this is that excluded regions are not part of the UUID. That's on design for good reasons.</p> <p>What we recommend is an implementation that serializes the SegmentHeader (it implements Serializable and hashCode() & equals()) and use that directly as a binary key that you propagate, so that it will retain the invalidated regions and keep everything nicely in sync.</p> <p>You should look at how we've implemented it in the <a href="https://github.com/pentaho/mondrian/blob/master/src/main/mondrian/rolap/cache/MemorySegmentCache.java" rel="nofollow">default memory cache</a>.</p> <p>There is also an <a href="https://github.com/webdetails/cdc" rel="nofollow">implementation using Hazelcast</a>.</p> <p>We at Pentaho have also used Infinispan with great success.</p> <blockquote> <p>how should getSegmentHeaders be implemented?</p> </blockquote> <p>Again, take a look at the default in-memory implementation. You simply need to return the list of all the currently known SegmentHeader. If you can't provide that list for whatever reason, either because you've used the UUID only, or because your storage backend doesn't support obtaining a list, like memcached, you return an empty list. Mondrian won't be able to use in-memory rollup and won't be able to share the segments, unless it hits the right UUIDs in cache.</p> <blockquote> <p>how are addListener and removeListener meant to be used?</p> </blockquote> <p>Mondrian needs to be notified when new elements appear in the cache. These could be created by other nodes. Mondrian maintains an index of all the segments it should know about (thus enabling in-memory operations), so that's a way to propagate the updates. You need to bridge the backend with the Mondrian instances here. Take a look at <a href="https://github.com/webdetails/cdc/blob/master/src/pt/webdetails/cdc/mondrian/SegmentCacheHazelcast.java#L104" rel="nofollow">how the Hazelcast implementation does it</a>.</p> <p>The idea behind this is that Mondrian maintains a spatial index of the currently known cells and will only query the necessary/missing cells from SQL if it absolutely needs to. This is necessary to achieve greater scalability. Fetching cells from SQL is extremely slow compared to objects which we maintain in an in-memory data grid.</p> <blockquote> <p>How do we make the SegmentCache re-use existing cache records on startup</p> </blockquote> <p>This is a caveat. Currently this is possible by applying <a href="https://github.com/pentaho/mondrian/pull/13/files" rel="nofollow">this patch</a>. It wasn't ported to the master codeline because it is a mess and is tangled with the fixes for another case. It has been reported to work, but wasn't tested internally by us. The relevant <a href="https://github.com/pentaho/mondrian/pull/13/files#L5L898" rel="nofollow">code is about here</a>. If you get around to testing this, we always welcome contributions. Let us know if you're interested on the <a href="http://lists.pentaho.org/mailman/listinfo/mondrian" rel="nofollow">mailing list</a>. There are a ton of people who will gladly help.</p> <p>One workaround is to update the local index through the listener when your cache implementation starts.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload