ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: IgniteSet implementation: changes required
Date Thu, 15 Feb 2018 20:20:53 GMT
On Thu, Feb 15, 2018 at 6:08 AM, Vladimir Ozerov <vozerov@gridgain.com>

> 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

Can you clarify why you believe that IgniteSet should need to have on-heap


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message