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.r...@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 <k...@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.r...@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 <k...@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.r...@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 <k...@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.r...@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" <k...@peernova.com>: > > > > > > > > > > > > > > thanks! > > > > > > > > > > > > > > On Thu, Feb 9, 2017 at 8:51 PM, Benjamin Roth < > > > > benjamin.r...@jaumo.com > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Yes it is > > > > > > > > > > > > > > > > Am 10.02.2017 00:46 schrieb "Kant Kodali" <k...@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 >
