[infinispan-dev] abstracting key locating, asymmetric clusters

Manik Surtani manik at jboss.org
Wed Jul 27 11:44:03 EDT 2011


Hi Christian, answers in-line.

On 19 Jul 2011, at 21:50, Christian Kulenkampff wrote:

> Hi all,
> I just want to share some thoughts on Infinispan. Probably you already
> had similar ideas, maybe you can provide some keywords, so I can
> search for discussions in the archive.
> 
> As I understand, the ConsistentHash works just as a consistent hash
> based "locator" for keys in the cluster. Basically one could implement
> full replication with a special ConsistentHash that always returns all
> addresses in the cluster. A ConsistentHash/"locator" has to be uniform
> over the entire cluster to make it work. In principle this is the only
> requirement for a "locator".
> Currently there is only one parameter for the "locator" - a set with
> all nodes in the cluster. If there would be a way to pass (maybe
> dynamically) more parameters to a "locator" in a consistent way, many
> possibilities would open up: e.g. an asymmetric cache configuration by
> feeding the locator with a distributed registry; switching hash
> functions at runtime; subscribable keys; keys, that have to stay at a
> special node…

Possibly, but this breaks the deterministic aspect of a ConsistentHash.  I.e., locating a key by any node in the cluster will not be possible.  Unless we share some additional metadata about each key (such as whether it is pinned, and where it is pinned to, etc).  And the consistency of this metadata will have to be very strong to ensure being able to find such a key.  So it isn't trivial to implement.  What specific use case are you trying to solve here?

> Also it may be possible to remove the replication mode
> and instead provide a special locator.

We considered this, however there is a lot of additional overhead and we wouldn't be able to make use of certain JGroups tricks to optimise sending the same state to all servers in the cluster.

> To make this work rebalancing
> would have to be more fine grained. E.g. it should be possible for the
> locator (or its manager?) to ignore a view change or to trigger some
> rebalance work per cache.

We are doing some of this anyway, for other reasons. There is a set of JIRAs targeted for 5.1 to address this.

Cheers
Manik
--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org






More information about the infinispan-dev mailing list