ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergi Vladykin <sergi.vlady...@gmail.com>
Subject Re: Performance vs correctness: I vote fore the second
Date Tue, 18 Apr 2017 09:21:08 GMT
We never read from backups on partitioned cache, but for replicated we do
that to be able to execute the whole query on single node locally.

Sergi

2017-04-18 12:07 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:

> Sergi, I am confused. If we don't read from backups, then why do we care
> about sync or async backup updates?
>
> On Tue, Apr 18, 2017 at 1:11 AM, Sergi Vladykin <sergi.vladykin@gmail.com>
> wrote:
>
> > Val,
> >
> > There we were not able to run queries against partitioned tables using
> > replicated cache API (I already fixed that in master).
> >
> > Here we are talking about query result inconsistency in case of
> > PRIMARY_SYNC
> > because of async backup update.
> >
> > Sergi
> >
> > 2017-04-18 11:04 GMT+03:00 Valentin Kulichenko <
> > valentin.kulichenko@gmail.com>:
> >
> > > Can you please elaborate then? What is the logic there?
> > >
> > > -Val
> > >
> > > On Tue, Apr 18, 2017 at 9:55 AM, Sergi Vladykin <
> > sergi.vladykin@gmail.com>
> > > wrote:
> > >
> > > > Val,
> > > >
> > > > That discussion has nothing to do with this PRIMARY_SYNC problem.
> > > >
> > > > Sergi
> > > >
> > > > 2017-04-18 10:51 GMT+03:00 Valentin Kulichenko <
> > > > valentin.kulichenko@gmail.com>:
> > > >
> > > > > Sergi,
> > > > >
> > > > > I'm talking about this discussion:
> > > > > http://apache-ignite-developers.2346864.n4.nabble.
> > > > > com/SQL-on-PARTITIONED-vs-REPLICATED-cache-td16478.html
> > > > >
> > > > > -Val
> > > > >
> > > > > On Tue, Apr 18, 2017 at 9:46 AM, Vladimir Ozerov <
> > vozerov@gridgain.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Val,
> > > > > >
> > > > > > PRIMARY_SYNC doesn't work correctly with the most common case
of
> > SQL
> > > > > query
> > > > > > execution over REPLICATED cache. Also it has weird consequences
> for
> > > > > > continuous queries when coupled with another
> > > > performance-over-correctness
> > > > > > property "readFromBackup=true": user may receive CQ notification
> > with
> > > > new
> > > > > > value, but subsequent GET on local node may return old value.
> > > > > >
> > > > > > On Tue, Apr 18, 2017 at 10:42 AM, Valentin Kulichenko <
> > > > > > valentin.kulichenko@gmail.com> wrote:
> > > > > >
> > > > > > > This sounds more like an issue with query execution, rather
> than
> > > > wrong
> > > > > > > PRIMARY_SYNC
> > > > > > > behavior. We already had a discussion about this optimization
> in
> > > > > > replicated
> > > > > > > cache and decided to switch it off by default.
> > > > > > >
> > > > > > > -Val
> > > > > > >
> > > > > > > On Tue, Apr 18, 2017 at 9:35 AM, Sergi Vladykin <
> > > > > > sergi.vladykin@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > With replicated cache we can execute a query against
backup
> > > > > partitions
> > > > > > > that
> > > > > > > > were not updated yet because of PRIMARY_SYNC. Thus
we do not
> > see
> > > an
> > > > > > > update.
> > > > > > > >
> > > > > > > > Sergi
> > > > > > > >
> > > > > > > > 2017-04-18 10:30 GMT+03:00 Dmitriy Setrakyan <
> > > > dsetrakyan@apache.org
> > > > > >:
> > > > > > > >
> > > > > > > > > Vladimir,
> > > > > > > > >
> > > > > > > > > What is wrong with a query in PRIMARY_SYNC mode?
Why won't
> it
> > > > work?
> > > > > > > > >
> > > > > > > > > D.
> > > > > > > > >
> > > > > > > > > On Tue, Apr 18, 2017 at 12:25 AM, Vladimir Ozerov
<
> > > > > > > vozerov@gridgain.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Folks,
> > > > > > > > > >
> > > > > > > > > > I received a number of complaints from users
that our
> > default
> > > > > > setting
> > > > > > > > > favor
> > > > > > > > > > performance at the cost of correctness and
subtle
> behavior.
> > > > > > > Yesterday I
> > > > > > > > > > faced one such situation on my own.
> > > > > > > > > >
> > > > > > > > > > I started REPLICATED cache on several nodes,
put some
> data,
> > > > > > executed
> > > > > > > > > simple
> > > > > > > > > > SQL and got wrong result. No errors, no
warnings. The
> > problem
> > > > was
> > > > > > > > caused
> > > > > > > > > by
> > > > > > > > > > default PRIMARY_SYNC mode. WTF, our cache
doesn't work
> out
> > of
> > > > the
> > > > > > > box!
> > > > > > > > > >
> > > > > > > > > > Another widely known examples are data streamer
behavior,
> > > "read
> > > > > > form
> > > > > > > > > > backups" + continuous queries.
> > > > > > > > > >
> > > > > > > > > > I propose to change our defaults to favor
*correctness*
> > over
> > > > > > > > performance,
> > > > > > > > > > and create good documentation and JavaDocs
to explain
> users
> > > how
> > > > > to
> > > > > > > tune
> > > > > > > > > our
> > > > > > > > > > product. Proposed changes:
> > > > > > > > > >
> > > > > > > > > > 1) FULL_SYNC as default;
> > > > > > > > > > 2) "readFromBackups=false" as default;
> > > > > > > > > > 3) "IgniteDataStreamer.allowOverwrite=true"
as default.
> > > > > > > > > >
> > > > > > > > > > Users should not think how to make Ignite
work correctly.
> > It
> > > > > should
> > > > > > > be
> > > > > > > > > > correct out of the box.
> > > > > > > > > >
> > > > > > > > > > Vladimir.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

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