On Thu, Feb 15, 2018 at 6:08 AM, Vladimir Ozerov <voze...@gridgain.com> wrote:
> I do not think indexes is the right approach - set do not have indexes, and > you will have to maintain additional counter for it in order to know when > to stop. > > From what I see there are two distinct problems: > 1) Broken recovery - this is just a bug which needs to be fixed. As soon as > data is stored in real persistent cache, recovery of data structure state > should be trivial task. > 2) Heap items - this should not be a problem in common case when set > contains moderate number of elements. If set is excessively large, then > this is not the right structure for your use case and you should use > standard IgniteCache API instead. What we can do is to optionally disable > on-heap caching for specific set at the cost of lower performance if user > wants so. > Vladimir, I am not sure I agree. In my view, set should be similar to cache, just a different API. I am not sure why we should make an assumptions that set data should be smaller than cache, especially given that it is a trivial task to implement a set based on Ignite cache API (we could just store key-key mappings in cache instead of key-value mappings internally). Can you clarify why you believe that IgniteSet should need to have on-heap entries? D.
