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 <k...@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.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 > > > -- 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
