Folks, Why don't we read data straight from the persistence layer warming RAM up in the background? (like we do for SQL and other APIs). If it's a question of time, then I would suggest us not to hurry up and do it in a right way.
-- Denis On Mon, Jun 25, 2018 at 6:20 AM Anton Vinogradov <a...@apache.org> wrote: > +1 to removal in case there is no easy, fast and consistent way to restore > setDataMap on node restart. > I see that we'll gain some performance drop on size() or keys(), but these > methods are rarely used. > > пн, 25 июн. 2018 г. в 16:07, Pavel Pereslegin <xxt...@gmail.com>: > > > Hello, Igniters. > > > > I tried to implement IgniteSet data recovery when persistence enabled > > [1] using trivial cache scanning, however I cannot find optimal way to > > do that because of the following reasons: > > - Performing operations on IgniteSet requires completion of data > > loading (restoring of setDataMap) on all nodes. Do this during > > partition map exchange is too long. > > - The prohibition of operations on IgniteSet before the completion of > > asynchronous cache scanning on all nodes looks rather complicated, > > because It is necessary to support all situations of unstable > > topology. > > > > So I see one option to fix data loss on node restart - remove the > > entire optimization (setDataMap) and rework the iterator > > implementation to perform cache scanning. > > > > Thoughts? > > > > [1] https://issues.apache.org/jira/browse/IGNITE-5553 > > > > > > 2018-03-17 8:20 GMT+03:00 Andrey Kuznetsov <stku...@gmail.com>: > > > Thanks, Dmitry. I agree ultimately, DS API uniformity is a weighty > > reason. > > > > > > 2018-03-17 3:54 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > > > > > >> On Fri, Mar 16, 2018 at 7:39 AM, Andrey Kuznetsov <stku...@gmail.com> > > >> wrote: > > >> > > >> > Dmitry, your way allows to reuse existing {{Ignite.set()}} API to > > create > > >> > both set flavors. We can adopt it unless somebody in the community > > >> objects. > > >> > Personally, I like {{IgniteCache.asSet()}} approach proposed by > > Vladimir > > >> O. > > >> > more, since it emphasizes the difference between sets being created, > > but > > >> > this will require API extension. > > >> > > > >> > > >> Andrey, I am suggesting that Ignite.set(...) in non-collocated mode > > behaves > > >> exactly the same as the proposed IgniteCache.asSet() method. I do not > > like > > >> the IgniteCache.asSet() API because it is inconsistent with Ignite > data > > >> structure design. All data structures are provided on Ignite API > > directly > > >> and we should not change that. > > >> > > >> D. > > >> > > > > > > > > > > > > -- > > > Best regards, > > > Andrey Kuznetsov. > > >
