Folks, Do we have a consensus so far that MVCC should be annotated with @IgniteExperimental? Are there any objections?
Best regards, Ivan Pavlukhin пт, 7 февр. 2020 г. в 15:58, Roman Kondakov <kondako...@mail.ru.invalid>: > > I absolutely agree with Alexey that MVCC architecture should be > completely reviewed. Current implementation is uncompetitive with other > solutions. It is slow by design. Here are some my points: > - we use central coordinator for transactions ordering. This is very > similar to what Calvin [1] systems do. But unlike them we also use 2pc > for distributed commit. So, we always have several additional network > hops for each transaction and every Calvin system (FaunaDB, YandexDB) > will outperform Ignite by design. > - We write uncommitted data to the page memory and WAL and this slows > down transactions even more. > > I am a supporter of complete revising of the MVCC design. > > [1] http://cs.yale.edu/homes/thomson/publications/calvin-sigmod12.pdf > > -- > Kind Regards > Roman Kondakov > > > On 07.02.2020 15:21, Alexei Scherbakov wrote: > > My point is MVCC should be redone from scratch without messing with other > > pars of code. > > > > Currently it's spaghetti unmaintanable code. > > > > пт, 7 февр. 2020 г. в 14:52, Ivan Pavlukhin <vololo...@gmail.com>: > > > >> My humble opinion. > >> > >> We need MVCC because it is our way to SQL transactions. SQL is a very > >> important user API (as you might know there is an active work on new > >> SQL engine). Fair SQL transactions is a supplementary and quite needed > >> feature, users ask about it on user list. I believe it is a future of > >> Ignite. > >> > >> Best regards, > >> Ivan Pavlukhin > >> > >> пт, 7 февр. 2020 г. в 13:23, Seliverstov Igor <gvvinbl...@gmail.com>: > >>> > >>> Note that someone uses it > >>> > >>> Main problem is a recovery process when persistence enabled and a > >> cluster have more than one node. > >>> > >>> It is a problem even for regular transactional caches, the main > >> difference - MVCC detects any inconsistencies while regular transactional > >> caches may ignore it without any notification > >>> > >>> In other cases it works fine and provides promised guaranties. > >>> > >>> Of course there are several minor issues like performance ones, but > >> there is a plan how to solve them (I could share it if anybody is curious) > >>> > >>> My opinion we should solve consistency issues first and finalize MVCC > >> after that. > >>> > >>> Until that it’s OK to have it as experimental feature. > >>> > >>> Regards, > >>> Igor > >>> > >>>> 6 февр. 2020 г., в 21:25, Alexei Scherbakov < > >> alexey.scherbak...@gmail.com> написал(а): > >>>> > >>>> I'm strongly support removal of MVCC from master. > >>>> > >>>> At the current state it bloats code base and should be reworked from > >>>> scratch using separate code base. > >>>> > >>>> чт, 6 февр. 2020 г. в 19:45, Ilya Kasnacheev < > >> ilya.kasnach...@gmail.com>: > >>>> > >>>>> Hello! > >>>>> > >>>>> Please keep in mind that you need to create a separate proposal voting > >>>>> thread if you really like it to count. I wonder if Dmitry Pavlov can > >> help > >>>>> us with the procedure. > >>>>> > >>>>> Otherwise, I think it makes total sense to restrict MVCC clusters to > >> only > >>>>> have MVCC caches or REPLICATED TRANSACTIONAL caches (are they > >> compatible in > >>>>> our current implementation) and no ATOMIC caches at all. > >>>>> > >>>>> Regards, > >>>>> -- > >>>>> Ilya Kasnacheev > >>>>> > >>>>> > >>>>> чт, 6 февр. 2020 г. в 19:41, Maxim Muzafarov <mmu...@apache.org>: > >>>>> > >>>>>> Ilya, > >>>>>> > >>>>>> > >>>>>> 1. MVCC support requires code maintenance for other developed > >> features > >>>>>> even if has not used and disabled. Currently, we've got an x2 level > >> of > >>>>>> difficulty for implementation of new features. > >>>>>> > >>>>>> 2. It would be much easy to develop and support clusters with > >>>>>> mvcc-caches only rather than have a mixed configuration. With this > >>>>>> option we can dramatically reduce the amount of codebase removing > >> from > >>>>>> mvcc-branch local, atomic, tx caches. > >>>>>> > >>>>>> > >>>>>> So, I'm +1 to remove it from the master branch and mark the current > >>>>>> API with @IgniteExperimental. > >>>>>> > >>>>>> On Thu, 6 Feb 2020 at 19:29, Ilya Kasnacheev < > >> ilya.kasnach...@gmail.com> > >>>>>> wrote: > >>>>>>> > >>>>>>> Hello! > >>>>>>> > >>>>>>> Why would we drop MVCC!? > >>>>>>> > >>>>>>> I can totally imagine a scenario where a large Ignite user surfaces > >>>>> with > >>>>>>> fixes for MVCC mode, if it is kept as an experimental feature. Then > >>>>> maybe > >>>>>>> it will graduate to beta some time in future. > >>>>>>> > >>>>>>> If it does too much strain on the TC, let's discuss that, but I > >> don't > >>>>>>> remember problems with TC load lately, so maybe this is a moot > >> point. > >>>>>>> > >>>>>>> Regards, > >>>>>>> -- > >>>>>>> Ilya Kasnacheev > >>>>>>> > >>>>>>> > >>>>>>> чт, 6 февр. 2020 г. в 15:27, Nikolay Izhikov <nizhi...@apache.org>: > >>>>>>> > >>>>>>>>> By the way, is there any reason to have this code in the master > >>>>>> branch > >>>>>>>> > >>>>>>>> I support removal MVCC from master. > >>>>>>>> > >>>>>>>> > >>>>>>>>> 6 февр. 2020 г., в 15:26, Andrey Gura <ag...@apache.org> > >>>>> написал(а): > >>>>>>>>> > >>>>>>>>> +1 > >>>>>>>>> > >>>>>>>>> By the way, is there any reason to have this code in the master > >>>>>>>>> branch? It seems feature is in unsupportable state and just wastes > >>>>> TC > >>>>>>>>> time and our effort to support MVCC related tests. > >>>>>>>>> > >>>>>>>>> On Thu, Feb 6, 2020 at 2:44 PM Alexey Goncharuk > >>>>>>>>> <alexey.goncha...@gmail.com> wrote: > >>>>>>>>>> > >>>>>>>>>> Agree, let's mark MVCC experimental. > >>>>>>>>>> > >>>>>>>>>> Stephen, the annotation serves as an additional > >>>>> documentation-style > >>>>>>>> marker. > >>>>>>>>>> For now there are no compile-time warnings when the API is used. > >>>>>>>>>> > >>>>>>>>>> чт, 6 февр. 2020 г. в 14:35, Stephen Darlington < > >>>>>>>>>> stephen.darling...@gridgain.com>: > >>>>>>>>>> > >>>>>>>>>>> Yes! I’ve already seen people try to use this without awareness > >>>>>> that > >>>>>>>> it’s > >>>>>>>>>>> not production ready. > >>>>>>>>>>> > >>>>>>>>>>> What happens with the annotation, incidentally? Is it just in > >> the > >>>>>>>>>>> documentation or do you get a compile-time warning? > >>>>>>>>>>> > >>>>>>>>>>>> On 6 Feb 2020, at 11:32, Nikolay Izhikov <nizhi...@apache.org> > >>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> Hello, Igniters. > >>>>>>>>>>>> > >>>>>>>>>>>> Should we mark MVCC feature with the new @IgniteExperimental? > >>>>>>>>>>>> > >>>>>>>>>>>> We explicitly note users that MVCC has beta status, for now [1] > >>>>>>>>>>>> > >>>>>>>>>>>>> Beta version of Transactional SQL and MVCC > >>>>>>>>>>>>> In Ignite v2.7, Transactional SQL and MVCC are released as > >> beta > >>>>>>>>>>> versions to allow users to experiment and share feedback. > >>>>>>>>>>>>> This version of Transactional SQL and MVCC should not be > >>>>>> considered > >>>>>>>> for > >>>>>>>>>>> production. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> [1] > >>>>>>>> > >> https://apacheignite.readme.io/docs/multiversion-concurrency-control > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>>> -- > >>>> > >>>> Best regards, > >>>> Alexei Scherbakov > >>> > >> > > > >
