cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Roth <benjamin.r...@jaumo.com>
Subject Re: If reading from materialized view with a consistency level of quorum am I guaranteed to have the most recent view?
Date Fri, 10 Feb 2017 19:04:45 GMT
No your example has different PRIMARY keys but same PARTITION keys. Same
partition keys generate same token and will always go to the same host.

2017-02-10 19:58 GMT+01:00 Kant Kodali <kant@peernova.com>:

> In that case I can't even say same partition key == same row key
>
> The below would be different partition keys according to you right?
>
> PRIMARY KEY ((a, b), c, d) and
> PRIMARY KEY ((a, b), d, c, e)
>
> On Fri, Feb 10, 2017 at 10:48 AM, Benjamin Roth <benjamin.roth@jaumo.com>
> wrote:
>
> > Same partition key:
> >
> > PRIMARY KEY ((a, b), c, d) and
> > PRIMARY KEY ((a, b), d, c)
> >
> > PRIMARY KEY ((a), b, c) and
> > PRIMARY KEY ((a), c, b)
> >
> > Different partition key:
> >
> > PRIMARY KEY ((a, b), c, d) and
> > PRIMARY KEY ((a), b, d, c)
> >
> > PRIMARY KEY ((a), b) and
> > PRIMARY KEY ((b), a)
> >
> >
> > 2017-02-10 19:46 GMT+01:00 Kant Kodali <kant@peernova.com>:
> >
> > > Okies now I understand what you mean by "same" partition key.  I think
> > you
> > > are saying
> > >
> > > PRIMARY KEY(col1, col2, col3) == PRIMARY KEY(col2, col1, col3) // so
> far
> > I
> > > assumed they are different partition keys.
> > >
> > > On Fri, Feb 10, 2017 at 10:36 AM, Benjamin Roth <
> benjamin.roth@jaumo.com
> > >
> > > wrote:
> > >
> > > > There are use cases where the partition key is the same. For example
> if
> > > you
> > > > need a sorting within a partition or a filtering different from the
> > > > original clustering keys.
> > > > We actually use this for some MVs.
> > > >
> > > > If you want "dumb" denormalization with simple append only cases (or
> > more
> > > > general cases that don't require a read before write on update) you
> are
> > > > maybe better off with batched denormalized atomics writes.
> > > >
> > > > The main benefit of MVs is if you need denormalization to sort or
> > filter
> > > by
> > > > a non-primary key field.
> > > >
> > > > 2017-02-10 19:31 GMT+01:00 Kant Kodali <kant@peernova.com>:
> > > >
> > > > > yes thanks for the clarification.  But why would I ever have MV
> with
> > > the
> > > > > same partition key? if it is the same partition key I could just
> read
> > > > from
> > > > > the base table right? our MV Partition key contains the columns
> from
> > > the
> > > > > base table partition key but in a different order plus an
> additional
> > > > column
> > > > > (which is allowed as of today)
> > > > >
> > > > > On Fri, Feb 10, 2017 at 10:23 AM, Benjamin Roth <
> > > benjamin.roth@jaumo.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > It depends on your model.
> > > > > > If the base table + MV have the same partition key, then the
MV
> > > > mutations
> > > > > > are applied synchronously, so they are written as soon the write
> > > > request
> > > > > > returns.
> > > > > > => In this case you can rely on the R+F > RF
> > > > > >
> > > > > > If the partition key of the MV is different, the partition of
the
> > MV
> > > is
> > > > > > probably placed on a different host (or said differently it
> cannot
> > be
> > > > > > guaranteed that it is on the same host). In this case, the MV
> > updates
> > > > are
> > > > > > executed async in a logged batch. So it can be guaranteed they
> will
> > > be
> > > > > > applied eventually but not at the time the write request returns.
> > > > > > => You cannot rely and there is no possibility to absolutely
> > > guarantee
> > > > > > anything, not matter what CL you choose. A MV update may always
> > > "arrive
> > > > > > late". I guess it has been implemented like this to not block
in
> > case
> > > > of
> > > > > > remote request to prefer the cluster sanity over consistency.
> > > > > >
> > > > > > Is it now 100% clear?
> > > > > >
> > > > > > 2017-02-10 19:17 GMT+01:00 Kant Kodali <kant@peernova.com>:
> > > > > >
> > > > > > > So R+W > RF doesnt apply for reads on MV right because
say I
> set
> > > > QUORUM
> > > > > > > level consistency for both reads and writes then there
can be a
> > > > > scenario
> > > > > > > where a write is successful to the base table and then
say
> > > > immediately
> > > > > I
> > > > > > do
> > > > > > > a read through MV but prior to MV getting the update from
the
> > base
> > > > > table.
> > > > > > > so there isn't any way to make sure to read after MV had
been
> > > > > > successfully
> > > > > > > updated. is that correct?
> > > > > > >
> > > > > > > On Fri, Feb 10, 2017 at 6:30 AM, Benjamin Roth <
> > > > > benjamin.roth@jaumo.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi Kant
> > > > > > > >
> > > > > > > > Is it clear now?
> > > > > > > > Sorry for the confusion!
> > > > > > > >
> > > > > > > > Have a nice one
> > > > > > > >
> > > > > > > > Am 10.02.2017 09:17 schrieb "Kant Kodali" <kant@peernova.com
> >:
> > > > > > > >
> > > > > > > > thanks!
> > > > > > > >
> > > > > > > > On Thu, Feb 9, 2017 at 8:51 PM, Benjamin Roth <
> > > > > benjamin.roth@jaumo.com
> > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Yes it is
> > > > > > > > >
> > > > > > > > > Am 10.02.2017 00:46 schrieb "Kant Kodali" <
> kant@peernova.com
> > >:
> > > > > > > > >
> > > > > > > > > > If reading from materialized view with a
consistency
> level
> > of
> > > > > > quorum
> > > > > > > am
> > > > > > > > I
> > > > > > > > > > guaranteed to have the most recent view?
other words is w
> > + r
> > > > > n
> > > > > > > > > contract
> > > > > > > > > > maintained for MV's as well for both reads
and writes?
> > > > > > > > > >
> > > > > > > > > > Thanks!
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Benjamin Roth
> > > > > > Prokurist
> > > > > >
> > > > > > Jaumo GmbH · www.jaumo.com
> > > > > > Wehrstraße 46 · 73035 Göppingen · Germany
> > > > > > Phone +49 7161 304880-6 · Fax +49 7161 304880-1
> > > > > > AG Ulm · HRB 731058 · Managing Director: Jens Kammerer
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Benjamin Roth
> > > > Prokurist
> > > >
> > > > Jaumo GmbH · www.jaumo.com
> > > > Wehrstraße 46 · 73035 Göppingen · Germany
> > > > Phone +49 7161 304880-6 · Fax +49 7161 304880-1
> > > > AG Ulm · HRB 731058 · Managing Director: Jens Kammerer
> > > >
> > >
> >
> >
> >
> > --
> > Benjamin Roth
> > Prokurist
> >
> > Jaumo GmbH · www.jaumo.com
> > Wehrstraße 46 · 73035 Göppingen · Germany
> > Phone +49 7161 304880-6 · Fax +49 7161 304880-1
> > AG Ulm · HRB 731058 · Managing Director: Jens Kammerer
> >
>



-- 
Benjamin Roth
Prokurist

Jaumo GmbH · www.jaumo.com
Wehrstraße 46 · 73035 Göppingen · Germany
Phone +49 7161 304880-6 · Fax +49 7161 304880-1
AG Ulm · HRB 731058 · Managing Director: Jens Kammerer

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