>> Why don't we read data straight from the persistence layer warming RAM up >> in the background? Because it's not a trivial task to finish such loading on unstable topology. That's possible, ofcourse, but solution and complexity will be almost equals to WAL enable/disable.
пн, 25 июн. 2018 г. в 22:13, Denis Magda <dma...@apache.org>: > 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. > > > > > >
