How is index data managed within the cluster?

Question

Hello
We are in the process of evaluating Coherence.
With regard to indexes, am I correct in thinking that the data for the index is stored in an (internally managed) cache on the same node as the attendant indexed values? I'm not interested in getting at the index data, but rather just understanding how the index data itself is treated/stored within the cluster.
So in a 2 node cluster where an index is applied to a distributed cache that only has 2 entries, will there be an index cache on each node that has 1 {Binary,key} entry where the key points to the value that is stored on that same node? That is, I trust that the index data is spread out across the cluster in the case of a partitioned topology?
Regards
Peter

Answer 1

user11279467 wrote:
Hello
We are in the process of evaluating Coherence.
With regard to indexes, am I correct in thinking that the data for the index is stored in an (internally managed) cache on the same node as the attendant indexed values? I'm not interested in getting at the index data, but rather just understanding how the index data itself is treated/stored within the cluster.
So in a 2 node cluster where an index is applied to a distributed cache that only has 2 entries, will there be an index cache on each node that has 1 {Binary,key} entry where the key points to the value that is stored on that same node? That is, I trust that the index data is spread out across the cluster in the case of a partitioned topology?
Regards
PeterHi Peter,
up to 3.4.x indexes were supported only on partitioned topology, and yes, indexes on each node contain only data corresponding to entries which have their primary copy on that node (referred to as local entries from now on).
The indexes are not stored in a cache but they are managed as part of the information Coherence maintains about the backing map (the map which contains local entries).
The indexes are made of 2 parts:
- forward index: this is a mapping from the cache key in an internal representation (backing map keys from now on) to the value extracted with the extractor used to create the index from the entry belonging to the cache key (extracted value from now on)
- reverse index (aka. reverse map): this is a mapping from the extracted value to a set of backing map keys of entries from which the reverse index key was extracted with the extractor used to create the index
The index can be sorted which means that the reverse index will be a SortedMap (so sorting order is the ordering of extracted values)
Let's see an example. Assuming you have the following cache content within a particular storage-enabled node :
A --> Object (getX=5 ,...)
B --> Object (getA=3 ,...)
C --> Object (getA=3 ,...)
D --> Object (getA=4 ,...)
The forward index in that node will contain:
Binary(A) --> 5
Binary(B) --> 3
Binary(C) --> 3
Binary(D) --> 4
The reverse index will contain:
3 --> { Binary(B), Binary(C) }
4 --> { Binary(D) }
5 --> { Binary(A) }
Where Binary(...) means the internal (binary) representation of the ... object.
If the index is not ordered, then the order of iteration on entries in the reverse index are not deterministic.
If the index is ordered, then the iteration of entries in the reverse index will be as shown above. Also, you can cast the reverse index to SortedMap so you have the very useful headMap and tailMap and firstKey and lastKey methods.
Hope this helps.
Best regards,
Robert