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
